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:sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
