Search for Strong number in OSHB shows nothing about xiphos HOT 7 CLOSED

I intend to babble at sword-devel first, sometime today.

from xiphos.

Now that's darn peculiar.

Once upon a nightmare, when I added the search button to the dict pane (#891), this was part of the new code:

	/* heb numbers use a pointless leading 0, grk does not. */
        if (hebrew) --start;

So this was actually deliberate. Backing up start was specifically to include a leading zero. In fact, a crash case later made me update slightly:

	if (hebrew && (start > key))
		--start;

It is a certainty that this worked as expected at the time. I can only guess that some underlying Sword update has altered the behavior.

The workaround for the moment is to open the sidebar search where you will find the constructed search case, remove the leading zero, and re-run the search. I will have to experiment to find out whether avoiding the leading zero is a general solution.

from xiphos.

Oh, I should have explained: Early in Sword, an otherwise useless leading zero was how Heb vs Grk Strong's refs were distinguished, and thus the KJV module is, or was, encoded. So it was quite relevant in that regard. Over time, in many contexts the discriminant changed to use a leading H or G.

from xiphos.

thank you Karl for the work around. I hope you will have some time to solve this.

from xiphos.

This got really ugly in a hurry.

The problem is the fundamental indecision between two competing, mutually-exclusive ideas of what a Strong's number ontologically is. Either
[a] a Strong's number is a number, stored for convenience as a fixed string of characters
or
[b] a Strong's number is a fixed string of characters where every character matters

The reason it doesn't work in some Bibles is because those Bibles do not encode the critical leading zero at the beginning. Consider Gen.1.1 first word in 5 Bibles:

KJV works:

<w savlm="strong:H07225">In the beginning</w>

ESV works:

In the <w savlm="strong:H07225">beginning</w>

NASB fails:

<w savlm="strong:H7225">In the beginning</w>

OSHB fails:

<w savlm="strong:H7225">בראשׁית</w>

hboWLC fails:

<w savlm="strong:H7225">בראשׁית</w>

Working vs. failing is distinguished by whether the module has encoded a leading zero in Strong's refs. That is, failing is because the Strong's number is just a number, using exactly as many digits as it needs in common writing; working is because the Strong's number is a string encoding which has been peculiarly zero-prefixed. The key to construct the search, taken from the dictionary pane, is always exactly 5 digits, zero-filled, and that is what is inserted, without the leading zeroes, into the search string, except that in the Hebrew case, one leading zero is left. That string is then what is searched in lemmas of the module.

Modules which uses numbers as numbers-merely-written-as-strings thus fail because there is never a match with a leading zero.

I have no idea at this moment how to resolve this conflict in the code. There is no indication in e.g. the module's configuration as to whether Hebrew Strong's numbers are zero-prefixed. What if not all Strong's refs in a module are zero-prefixed? Then some refs would be found and some not. Also I am not aware that we can claim the markup is wrong in being not-zero-prefixed, that is, there is no standard to which we can refer to say that unprefixed Hebrew Strong's numbers are incorrect refs.

This is madness.

from xiphos.

Maybe we need to open an issue on the openscripture github?

from xiphos.

The OSHB was updated in the repo. I close for now this issue.

from xiphos.