daniel added a subscriber: daniel. daniel added a comment. This issue is fallout of https://phabricator.wikimedia.org/T90692. The suggester uses the contents of "aliases" to indicate why a term was matched (if the label wasn't the match, it would have to be the alias). So when changing the search infrastructure that backs wbsearchentities, we simply added the matched label as the "alias" for backwards compatibility. This will indeed often be redundant.
The patch above (Ia5eaa1ba74a4f6f) will exclude matched labels from "aliases" to avoid the redundancy. This however only works if the search language and the display language are the same - if they are not, we *need* the matched label somewhere, otherwise it's not possible to see why a given item was found in the search. I instead suggest to provide the matched term in "aliases" if it's different from the display label. If not, the "aliases" key should not be present in the result at all (instead of containing an empty array), to avoid the issues mentioned in the description. TASK DETAIL https://phabricator.wikimedia.org/T104273 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, gerritbot, aude, Aklapper, Wikidata-bugs, Malyacko, P.Copp _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
