Re: OSHB module

Le 14/03/2024 à 22:23, Karl Kleinpaste a écrit :
> 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.

Personally, I also support the fact that we make a decision, but I don't 
know who decides that.
>
> 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

_______________________________________________
sword-devel mailing list: [email protected]
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page