[sword-devel] Strong's numbers: Numbers or strings

[Fr Cyrille]

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 <karl at kleinpaste.org> 
> wrote:
>> I have a Xiphos bug <https://github.com/crosswire/xiphos/issues/1107> 
>> 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:sword-devel at crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/sword-devel/attachments/20220127/0a78011a/attachment.html>