<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Karl,</p>
<p>Yes, this history of how to record Strong's numbers has a long
and inglorious history. The zero prefix was how the "Online
Bible", from which came most free online Bible resources back in
the 1980s, recorded Hebrew Strong's. The Bible Foundation (the
primary initial provider of data for the Online Bible), trusted us
with their data they provided to the Online Bible for the open
source community. Most modules we distributed from 1980-1990 were
sourced from the Bible Foundation.</p>
<p>I can't remember when we began using G and H prefixes to
disambiguation Strong's Hebrew numbers from Strong's Greek
numbers-- it may have been in the KJV2003 project. We later
adopted logic to allow Strong's numbers to have suffixes like
1234b and OSIS allow '!' to split suffixes, so we allowed 1234!c,
but enough about history.</p>
<p>Today, we have this odd bit of code in the engine to try to fix
all of this for the frontend developer, such that they shouldn't
need to do anything special, but simply use any 'G' or 'H' prefix
to determine which module you want to use for resolution, and pass
the remainder to the module:</p>
<p><a class="moz-txt-link-freetext" href="https://crosswire.org/svn/sword/trunk/src/modules/lexdict/swld.cpp">https://crosswire.org/svn/sword/trunk/src/modules/lexdict/swld.cpp</a></p>
<p>scroll to the bottom, to the function strongsPad</p>
<p>It should do exactly what is required for you and you shouldn't
need to do any special logic.</p>
<p>Again, the frontend code probably should be something like:</p>
<p>SWModule *lex = verseKey.getTestament() == 2 ||
strongsKey.startsWith("G") ? strongGreek : strongsHebrew;</p>
<p></p>
<p>if (strongsKey.startsWith("G") || strongsKey.startsWith("H"))
strongsKey << 1; // shift the buffer left by one; i.e.,
drop the G or H<br>
</p>
<p>lex.setKey(strongsKey);</p>
<p>I know it's convoluted, but the history explains a bit of all the
cases we need to handle and we try to shield the frontend
developer the best we can:</p>
<p>1</p>
<p>G1<br>
</p>
<p>G1!a</p>
01
<p>H1</p>
<p>...<br>
</p>
<br>
<p><br>
</p>
<div class="moz-cite-prefix">On 1/27/22 06:27, Karl Kleinpaste
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6d3df4fc-7fd0-f9df-fdd3-3efad66e64d5@kleinpaste.org">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<font face="FreeSerif">I have a <a moz-do-not-send="true"
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> <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>
</body>
</html>