Quite honestly, the Real Solution™ to this problem is to bite the
bullet, make a concrete decision that Strong's numbers are to be encoded
in exactly one way, and re-work all existing modules to conform to that
standard. Personally, I advocate that such a standard would stipulate
Strong's numbers to be encoded in minimal (natural) digits: Encoding an
OT reference as "1" means a Heb Strong's dictionary key of "00001" and
an NT "1401" means a Grk Strong's dictionary key of "01401", that is,
zeroes to create dictionary module keys are prepended to natural numbers
to fill exactly 5 digits.
I've never bothered to attempt a final fix to this problem in Xiphos for
exactly the reason that, no matter which direction I might take, it will
be an unreliable hack; that in turn is because the very concept of a
leading '0' as a weak discriminant between Heb and Grk Strong's numbers
is itself an unreliable hack. Whenever the subsequent conceptual change
came along, to distinguish Heb/Grk numbers according to a leading H or G
(that is, lucene search using e.g. "lemma:G1401"), /that/ was the point
at which the leading-zero-encoding nonsense should have been forced into
the trash bin.
It was not, and here we are.
Probability of the Real Solution™ coming to pass: Vanishingly close to zero.
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
