<html><head></head><body>   <div>What Karl has observed is a long-standing problem.</div><div><br></div><div>Might it be feasible to employ a suitable regular expression to match the Strong’s H number whether or not it has any leading zero[s]?</div><div><br></div><div>This would have to be done under the hood for this type of search, as it’s quite a different task than a user entered regex search.</div><div><br></div><div>But should such a workaround be better implemented in the SWORD API rather than as a kludge in a front-end?</div><div><br></div><div>And if so, how should JSword based front-ends also address the issue?<caret></caret></div><div><br></div><div>David</div><div><br></div> <div id="protonmail_mobile_signature_block"><div>Sent from ProtonMail for iOS</div></div> <div><br></div><div><br></div>On Thu, Jan 27, 2022 at 13:27, Karl Kleinpaste <<a href="mailto:karl@kleinpaste.org" class="">karl@kleinpaste.org</a>> wrote:<blockquote class="protonmail_quote" type="cite">





    <font face="FreeSerif">I have a <a href="https://github.com/crosswire/xiphos/issues/1107">Xiphos
        bug</a> in which the facility to take a Strong's dict entry and
      search the Bible module for all its occurrences sometimes works
      and sometimes doesn't.<br>
      <br>
      The mechanism is straightforward: Take the key from the dict pane,
      note whether this is Heb or Grk, construct e.g. lemma:Hxxxxx,
      stuff that into the sidebar search, and execute the search. No
      sweat.<br>
      <br>
      The problem is with Heb refs. Because of the ancient habit that
      Heb Strong's refs are given a leading zero prefix (e.g. "07225")
      as a weak discriminant from Grk refs in the same number space, I
      actually handle this case explicitly. Strong's module keys are
      fixed, 5-digit strings, and the dict pane always shows this. When
      that key is taken to build the lemma search, I specifically
      include the last leading zero in the Heb case.<br>
      <br>
      This works in KJV and ESV where we find "<w
      savlm="strong:H07225">In the beginning</w>".<br>
      This fails in NASB and OSHB where we find "<w
      savlm="strong:H7225">In the beginning</w>".<br>
      Note H07225 vs H7225.<br>
      <br>
      The question revolves around what a Strong's ref ontologically is.
      Seriously, what is it?<br>
      Is it a number, written naturally with minimal required digits,
      stored for convenience in a character string?<br>
      Or is it a specific and fixed string of characters?<br>
      <br>
      In terms of module keys, it's a string of characters.<br>
      In terms of Bible markup, well... Opinion varies. As we see in
      this case, some Bibles encode as a natural number, occupying the
      normal (minimal) digits needed, but others take the fixed string
      approach so as to include a leading zero, but note that it's not a
      full, fixed, 5-digit string to match a dict key; it's just one
      leading zero, no matter how many natural digits follow. KJV
      encodes the 1st Heb ref as "01". Not "1" (natural number) and not
      "00001" (module key); just "01".<br>
      <br>
      Result is that, by constructing zero-prefixed searches, such
      searches always fail in Bibles using natural/minimal digits
      because there's never a zero-prefixed match.<br>
      <br>
      This is different from Grk refs, which are stored in dict modules
      the same as Heb dict keys -- fixed 5-digit -- but are always
      marked up as natural numbers using minimal digits.<br>
      <br>
      As matters stand, I have no <i>a priori</i> means by which to
      determine what to expect in a Bible's Heb Strong's markup. The
      dict pane's key from which to construct the search is fixed 5
      digits. That is at first trimmed to natural, minimal digits...and
      then the trouble starts because I don't have anything like a
      module conf directive to tell me whether the module uses
      zero-prefixed Heb refs or not. I'm also not aware that we have any
      standard for such markup to which I can point to say, "NASB's
      markup is wrong because it lacks zero-prefixing on Heb refs."<br>
      <br>
      Help.<br>
    </font>

</blockquote></body></html>