Re: OSHB module

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: [email protected]
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page