<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<blockquote type="cite" cite="mid:3000206.is2rUzJNzf@brooks">On
5/14/24 5:20 PM, David "Judah's Shadow" Blue wrote:
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
I'm sure I could add some logic to check the given module and adapt the
token to fit, but that doesn't help the other issue I've found. When
searching for, say, G11 in a module that isn't 0 padded, all occurrences
of G11 are found, but so are all occurrences of G110, G1105, etc.
Assuming that normalization of padding on the entity attributes adds
padding to them so it's in the form of G0XXXX, that should cut down on
the false matches significantly.
In node-sword-interface I added some logic for this, so that the user does
not have to consider that.
<a class="moz-txt-link-freetext" href="https://github.com/ezra-bible-app/node-sword-interface/blob/794c349bece231">https://github.com/ezra-bible-app/node-sword-interface/blob/794c349bece231</a>
e2aa58bdacb7fe4aaffe774bcf/src/sword_backend/module_search.cpp#L146>
// If the Strong's key is OT we need to insert a zero in front
of the key
// This is necessary because the Sword modules with Strong's
have a zero in front of the Hebrew Strong's numbers
if (searchTerm[0] == 'H' &&
this->_textProcessor.moduleHasStrongsZeroPrefixes(module)) {
// Cut out the number from the Strong's key (starting at
index 1 until end of string)
string strongsKey = searchTerm.substr(1,
searchTerm.size());
// Overwrite the searchTerm with an inserted 0
searchTerm = "H0" + strongsKey;
}
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I just checked in diatheke and it looks like this will fail for the NASB, for
instance, because the NASB doesn't have leading 0s in either Testament.
And the bigger issue in my interface, when you retrieve a Strong's number from
the lexicon by searching for a term (i.e. Alpha), it passes through the
strongsPadding logic and gets leading 0's added. Until strongsPadding is added
to the entity attribute search in the SWORD engine, I may fall back to
stripping 0's out of the users input if the first search comes up empty. But
that still won't solve the issue of searching for G matching G11, and so on.
For that, I feel, the solution is to do use the strongsPadding logic on the
entity attributes since that seems to add leading 0's.</pre>
</blockquote>
<p>I don't think I have either of those issues in
node-sword-interface.</p>
<p>The module-based logic has the purpose that you prevent adding
the padding if the module does not have it - that's what the
helper function <a moz-do-not-send="true"
href="https://github.com/ezra-bible-app/node-sword-interface/blob/794c349bece231e2aa58bdacb7fe4aaffe774bcf/src/sword_backend/text_processor.cpp#L610">moduleHasStrongsZeroPrefixes</a>()
is for.<br>
</p>
<p>Regarding the issue with G1 also matching G11, etc. I have the
following snippet of code below the section I posted above:</p>
<p> // from swmodule.h api docs:<br>
// for use with entryAttrib search type to match whole
entry to value, e.g., G1234 and not G12345<br>
flags |= SWModule::SEARCHFLAG_MATCHWHOLEENTRY;<br>
<br>
searchTerm = "Word//Lemma./" + searchTerm;</p>
<p>Best regards,<br>
Tobias<br>
</p>
<p><br>
</p>
</body>
</html>