<!DOCTYPE html>

<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <font face="FreeSerif">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.<br>

      <br>

      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"), <i>that</i> was the

      point at which the leading-zero-encoding nonsense should have been

      forced into the trash bin.<br>

      <br>

      It was not, and here we are.<br>

      <br>

      Probability of the Real Solution™ coming to pass: Vanishingly

      close to zero.<br>

    </font>

  </body>

</html>