-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Search for Strong number in OSHB shows nothing #1107
Comments
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:
So this was actually deliberate. Backing up
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. |
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. |
thank you Karl for the work around. I hope you will have some time to solve this. |
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 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:
ESV works:
NASB fails:
OSHB fails:
hboWLC fails:
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. |
Maybe we need to open an issue on the openscripture github? |
I intend to babble at sword-devel first, sometime today. |
The OSHB was updated in the repo. I close for now this issue. |
When using the OSHB module, I click on a strong number, then on the magnifying glass, and no other link appears.
The text was updated successfully, but these errors were encountered: