On 5/14/24 5:20 PM, David "Judah's Shadow" Blue wrote:

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.


https://github.com/ezra-bible-app/node-sword-interface/blob/794c349bece231
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;
}
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.

I don't think I have either of those issues in node-sword-interface.

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 moduleHasStrongsZeroPrefixes <https://github.com/ezra-bible-app/node-sword-interface/blob/794c349bece231e2aa58bdacb7fe4aaffe774bcf/src/sword_backend/text_processor.cpp#L610>() is for.

Regarding the issue with G1 also matching G11, etc. I have the following snippet of code below the section I posted above:

            // from swmodule.h api docs:
            // for use with entryAttrib search type to match whole entry to value, e.g., G1234 and not G12345
            flags |= SWModule::SEARCHFLAG_MATCHWHOLEENTRY;

            searchTerm = "Word//Lemma./" + searchTerm;

Best regards,
Tobias


_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Reply via email to