<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 à 17:33, pierre amadio a
      écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:CAOTAUqKxjDuuM_P0hdM4-R2cc+EOS7wxRwkyJnSpro3bbOE6+g@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">Fixing this for the OSHB module should be trivial.
Let me know if you want me to do it.</pre>
    </blockquote>
    You mean directly on OSHB? This is a possibility. All module "just"
    add a zero in the good place...<br>
    <blockquote type="cite"
cite="mid:CAOTAUqKxjDuuM_P0hdM4-R2cc+EOS7wxRwkyJnSpro3bbOE6+g@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">

On Thu, 27 Jan 2022 at 17:20, Fr Cyrille <a class="moz-txt-link-rfc2396E" href="mailto:fr.cyrille@tiberiade.be"><fr.cyrille@tiberiade.be></a> wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">


Le 27/01/2022 à 15:07, David Haslam a écrit :

What Karl has observed is a long-standing problem.

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]?

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.

But should such a workaround be better implemented in the SWORD API rather than as a kludge in a front-end?

And if so, how should JSword based front-ends also address the issue?


AndBible reads very well the Strong hebrew numbers.


David

Sent from ProtonMail for iOS


On Thu, Jan 27, 2022 at 13:27, Karl Kleinpaste <a class="moz-txt-link-rfc2396E" href="mailto:karl@kleinpaste.org"><karl@kleinpaste.org></a> wrote:

I have a Xiphos bug 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.

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.

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.

This works in KJV and ESV where we find "<w savlm="strong:H07225">In the beginning</w>".
This fails in NASB and OSHB where we find "<w savlm="strong:H7225">In the beginning</w>".
Note H07225 vs H7225.

The question revolves around what a Strong's ref ontologically is. Seriously, what is it?
Is it a number, written naturally with minimal required digits, stored for convenience in a character string?
Or is it a specific and fixed string of characters?

In terms of module keys, it's a string of characters.
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".

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.

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.

As matters stand, I have no a priori 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."

Help.


_______________________________________________
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


_______________________________________________
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>
      <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>