<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi,<br>I'm not engaged in the design of Sword and JSword Engines but as i understand from the mentioned above, we depend on a library that get updates very frequently in java but no updates for its C port <br>If I'm right, Can we search for other libraries to use ?<br><br>The origin of the problem that Xiphos and other frontends can't search in Arabic when the source use diacritics and the search term doesn't contain any diacritics .<br><br>Thanks for your interest in solving the problem<br><br>Pola<br><br><div><div id="SkyDrivePlaceholder"></div>> Date: Mon, 26 Nov 2012 08:42:33 -0600<br>> From: greg.hellings@gmail.com<br>> To: sword-devel@crosswire.org<br>> Subject: Re: [sword-devel] Search bug & New Arabic Bible, Not Shaped SVD Version<br>> <br>> On Mon, Nov 26, 2012 at 8:12 AM, DM Smith <dmsmith@crosswire.org> wrote:<br>> > Correct. JSword uses Lucene's filter for the language, which does more normalization than the StandardAnalyzer which SWORD uses exclusively. The StandardAnalyzer should only be used for "unaccented" latinate text. Same with the SimpleAnalyzer. (In Lucene, an analyzer is a filter chain which normalizes text. Rule-of-Thumb: the same should be used for both index construction and searching.)<br>> ><br>> > Each release of Lucene adds and/or improves the filters for non-latin text.<br>> ><br>> > The biggest problem with using a new version of Lucene is that it invalidates, without notice, prior indexes. An analyzer may change from release to release. It has been true of the StandardAnalyzer. The impact is that the number of search hits may be reduced, perhaps to 0.<br>> ><br>> <br>> (Un?)Fortunately for SWORD it rarely will encounter this problem, as<br>> CLucene is extremely rarely updated. It has seen exactly two commits<br>> over the past 20 months (since the tagging of the 2.3.3.4 release,<br>> which is current head) and neither has been an update to the<br>> Analyzers. This has the benefit of not invalidating search indexes<br>> very often but has the drawback of almost never seeing updates to the<br>> analyzers and any bugs they may carry.<br>> <br>> It seems like we could have a set of Analyzers that we build on a<br>> per-language basis. The CLucene contrib libraries include analyzers<br>> specifically for German and CJK as examples. I doubt that the upstream<br>> maintainers would object to including additional analyzers if we<br>> developed them. That is, if we can even get in contact with them and<br>> they're not completely dormant.<br>> <br>> > Both SWORD and JSword need a mechanism to record the version of Lucene that is used in constructing an index and to refuse to search an index unless the version of Lucene for searching and indexing match.<br>> ><br>> <br>> Much noise has been made about this. But no one has been willing to<br>> actually implement it or been rebuffed when proposals have been made<br>> as to how this might be stored. Nearly any changes made would still<br>> lead to invalidation of existing indexes, against which there has been<br>> much friction in the past. Storing the value in a file next to the<br>> indexes is a near-trivial change, but no one has done so.<br>> <br>> To avoid this current issue, though, would it be better to track the<br>> Lucene version or the Analyzer version used? From what I know of<br>> Lucene, some sort of hybrid of the two might be best. My understanding<br>> is that some versions of Lucene break compatibility with indexes made<br>> in previous versions, while the current issue would be addressed by<br>> filter changes which should be applied to both the index and incoming<br>> search terms.<br>> <br>> Again, implementing this is a near trivial task (although<br>> compatibility between the indexes created in C and those in Java would<br>> probably not be possible because the Java Lucene library is much more<br>> active than CLucene). It's simply never been a priority for anyone to<br>> do.<br>> <br>> --Greg<br>> <br>> > Also of note, there have been some substantial changes to Unicode from release to release. So, if the version unicode used by the OS, Java, ICU, .... changes, the index may no longer be valid. From what I can tell this will be minority languages.<br>> ><br>> > In Him,<br>> > DM Smith<br>> ><br>> ><br>> > On Nov 26, 2012, at 7:22 AM, Peter von Kaehne <refdoc@gmx.net> wrote:<br>> ><br>> >><br>> >>> Von: David Haslam <dfhmch@googlemail.com><br>> >><br>> >>> So a similar patch would be necessary in principle to JSword ???<br>> >><br>> >> No. If And Bible does not have a problem, then Jsword does its job correctly.<br>> >><br>> >> Peter<br>> >><br>> >> _______________________________________________<br>> >> sword-devel mailing list: sword-devel@crosswire.org<br>> >> http://www.crosswire.org/mailman/listinfo/sword-devel<br>> >> Instructions to unsubscribe/change your settings at above page<br>> ><br>> ><br>> > _______________________________________________<br>> > sword-devel mailing list: sword-devel@crosswire.org<br>> > http://www.crosswire.org/mailman/listinfo/sword-devel<br>> > Instructions to unsubscribe/change your settings at above page<br>> <br>> _______________________________________________<br>> sword-devel mailing list: sword-devel@crosswire.org<br>> http://www.crosswire.org/mailman/listinfo/sword-devel<br>> Instructions to unsubscribe/change your settings at above page<br></div> </div></body>
</html>