Why not just add a normalization method to Sword? Ie. if the numeric reference starts with '0', pad it out to 5 digits?
John Dudeck
>
> 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?
>
> David
>
> Sent from ProtonMail for iOS
>
>
> On Thu, Jan 27, 2022 at 13:27, Karl Kleinpaste <k...@kleinpaste.org> 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.
John Dudeck Tel: +1-704-588-9891 Cell: +1-803-504-8065
john.dud...@sim.org Charlotte, North Carolina
--
One of the greatest gifts you can give someone
is thanking them for being part of your life.
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
