TJones added a comment.
I think we both have incorrect models of what's happening! **//Neat!//** I thought the apparent negation was removing the target file and something else on the Javascript side was putting it back in the wrong spot. You seem to have thought the Search API was putting the exact match specifically in the last spot. (But maybe not.) Turns out neither is correct. I'm still not 100% sure what's going on with the apparent negation. Without the //.jpg// at the end, the negation does in fact prevent the target from showing up. With it, it does show up, but not necessarily at the end. In fact, more often than not, the target is the first result! I //think// what is happening is that the exact match //is// being injected into the list on the backend, but not at any particular spot on the list. It gets a score and the result is whatever it is. In the cases of the `Barcelonnette - Villa du Parc du Mercantour...` searches, they happen to end up 10th out of 10. Others are first: - Benouville Churchyard -9.JPG <https://commons.wikimedia.org/w/api.php?action=query&list=search&srnamespace=6&srlimit=100&format=json&srsort=relevance&srsearch=Benouville%20Churchyard%20-9.JPG> - Rue des grands carmes 5 -9.jpg <https://commons.wikimedia.org/w/api.php?action=query&list=search&srnamespace=6&srlimit=100&format=json&srsort=relevance&srsearch=Rue%20des%20grands%20carmes%205%20-9.jpg> - Gmunden Kammerhofgasse 3 Arkadenhof -9173.jpg - Dug-out Zonnebeke -12.jpg Others are neither first nor last: - 2nd: Bourges - avenue du 95e-de-Ligne - Portail Saint-Ursin -991.jpg - 5th: Lannes (Lot-et-Garonne) - Église Sainte-Marie - Vitraux -9.JPG - 6th: Steyr Michaelerkirche Bürgerspital -9659.jpg <https://commons.wikimedia.org/w/api.php?action=query&list=search&srnamespace=6&srlimit=100&format=json&srsort=relevance&srsearch=Steyr%20Michaelerkirche%20B%C3%BCrgerspital%20-9659.jpg> - 34th: Eglise Notre Dame de l'Assomption.JPG <https://commons.wikimedia.org/w/api.php?action=query&list=search&srnamespace=6&srlimit=100&format=json&srsort=relevance&srsearch=Eglise%20Notre-Dame-de-l%27Assomption.JPG> So, the question now is whether we should try to modify search to push these results higher, overriding the current scoring method in some way, or whether the P18 search box should try to find any exact match, and either move it or insert it at the top of the list. The easiest solution, from my point of view, would be to use the completion suggester API instead of the regular search API for search-as-you-type, since it was designed for that. It does the exact right thing for all of these cases—but it only works for title/name–matching. Would it be possible to add a toggle to the P18 search box UI to allow the user to specify whether they are searching for a title match or doing a general search? (Just brainstorming.. but that might be the best of both worlds.) Modifying the search results might take a fairly long time to get on our schedule (likely), might slow down search (not sure), and might be subject to failure at a later date or causing weird side effects for some other search (depending on implementation). I'll put this on the agenda for our team meeting next Monday or Wednesday, and get an update back to you afterward. TASK DETAIL https://phabricator.wikimedia.org/T196165 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Silvan_WMDE, TJones Cc: EBernhardson, TJones, dcausse, Ladsgroup, Silvan_WMDE, Addshore, Bencemac, Aklapper, Ayack, Liuxinyu970226, Smalyshev, Lydia_Pintscher, Lea_Lacroix_WMDE, Iflorez, darthmon_wmde, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
