Glossary: Match single word entries of parts of speech that have no suffix rules.

[pedro-mendonca]

Problem

For any types of glossary items (part of speech), if the entry has multiple words won't try to add any suffixes, and is immediately added to the glossary list.

As explained in Meta Ticket https://meta.trac.wordpress.org/ticket/7473, if the glossary entry is a single word, currently it will only be added if there are rules for suffixes, which is wrong. Even if there isn't any rule, at least the exact word should be added.

Solution

For single word glossary terms of a part_of_speech that have no suffix rules, add the exact match to the glossary list.

Fixes #1790

Thanks @marcarmengou for reporting.

[pedro-mendonca]

There is one case on .org that I can't find the reason why isn't behaving the same:
The entry "FAQ" (abbreviation) is matched, despite every local tests having a different behaviour.
On my install, only after this PR the entry "FAQ" is matched.

I would expect this if there were any rules added for suffixes in the abbreviation array key in gp_glossary_match_suffixes.
But couldn't find any customization to the filter gp_glossary_match_suffixes on w.org.

A translation where it is matching
https://translate.wordpress.org/projects/wp/dev/admin/gl/default/?filters%5Bterm%5D=FAQ&filters%5Bcase_sensitive%5D=yes&filters%5Bterm_scope%5D=scope_originals&filters%5Bstatus%5D=current

The glossary where "FAQ" is added.
https://translate.wordpress.org/locale/pt/default/glossary/

[marcarmengou]

In Romanian and Swedish are marked as "expression" and are also currently matched.

Romanian: https://translate.wordpress.org/projects/wp/dev/admin/ro/default/?filters%5Bterm%5D=FAQ&filters%5Bcase_sensitive%5D=yes&filters%5Bterm_scope%5D=scope_originals&filters%5Bstatus%5D=current

Swedish: https://translate.wordpress.org/projects/wp/dev/admin/sv/default/?filters%5Bterm%5D=FAQ&filters%5Bcase_sensitive%5D=yes&filters%5Bterm_scope%5D=scope_originals&filters%5Bstatus%5D=current

[pedro-mendonca]

From my testing, found that for strings that are the exact match of the glossary, this isn't a problem, the match always happens.
The issue is exactly only for strings that contain the glossary match cases.

[pedro-mendonca]

Confirmed.
Strings that are multiple worded sentences are splitted by the glossary terms search made by gp_glossary_add_suffixes.
Then, these chunks are compared to the array of glossary keys. If the splitted term matches a key in the glossary terms array, there is a match.
For these cases, the current PR fixes the previously missing match.

For strings that are a single word, the splitting will always return the exact key of the glossary entry, so, it didn't have the issue of matching through the gp_glossary_add_suffixes.

[pedro-mendonca]

Added a test for all the same terms belonging to single term strings.
Are not needed for the current PR, because were already working fine, but adding here might help debugging for further issues.

Also, as there are many strings to test, updated the test with a Data provider.