<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">Le 27/01/2022 à 15:07, David Haslam a
      écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:zeIikPIDoY2J2dcGfz86Vz-JFBt0t4Lt53DYSy-O3hvMPkPR0DgSTuicXsSmQUR-5Hxf49Vnk42aZZchkprEXw1p1HdloZ_FimqoZ3pa_ug=@protonmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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?</div>
    </blockquote>
    <br>
    AndBible reads very well the Strong hebrew numbers.<br>
    <blockquote type="cite"
cite="mid:zeIikPIDoY2J2dcGfz86Vz-JFBt0t4Lt53DYSy-O3hvMPkPR0DgSTuicXsSmQUR-5Hxf49Vnk42aZZchkprEXw1p1HdloZ_FimqoZ3pa_ug=@protonmail.com">
      <div><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="moz-txt-link-freetext"
        moz-do-not-send="true">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"
            moz-do-not-send="true">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>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://crosswire.org/mailman/listinfo/sword-devel">http://crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page</pre>
    </blockquote>
    <br>
    <div id="grammalecte_menu_main_button_shadow_host" style="width:
      0px; height: 0px;"></div>
  </body>
</html>