[Wikidata-bugs] [Maniphest] [Commented On] T196165: Commons image: when pasting the exact title, get the correct file first in the suggester

Lea_Lacroix_WMDE added a comment. @Ayack The issue should now be fixed: can you try it from your side and let us know if you encounter further issues? TASK DETAIL https://phabricator.wikimedia.org/T196165 EMAIL PREFERENCES

[Wikidata-bugs] [Maniphest] [Commented On] T196165: Commons image: when pasting the exact title, get the correct file first in the suggester

Addshore added a comment. So this is currently using action=query and list=search. For example:

[Wikidata-bugs] [Maniphest] [Commented On] T196165: Commons image: when pasting the exact title, get the correct file first in the suggester

gerritbot added a comment. Change 572679 **merged** by jenkins-bot: [mediawiki/extensions/Wikibase@master] Update data-values/value-view submodule https://gerrit.wikimedia.org/r/572679 TASK DETAIL https://phabricator.wikimedia.org/T196165 EMAIL PREFERENCES

[Wikidata-bugs] [Maniphest] [Commented On] T196165: Commons image: when pasting the exact title, get the correct file first in the suggester

dcausse added a comment. I believe that because the file name has many words the score on the tokenized text fields is very high (since we sum all token scores), the score on the exact match having only one word and despite having a high weight it's not enough to compete with the loss of

[Wikidata-bugs] [Maniphest] [Commented On] T196165: Commons image: when pasting the exact title, get the correct file first in the suggester

gerritbot added a comment. Change 572679 had a related patch set uploaded (by Silvan Heintze; owner: Silvan Heintze): [mediawiki/extensions/Wikibase@master] Update data-values/value-view submodule https://gerrit.wikimedia.org/r/572679 TASK DETAIL

[Wikidata-bugs] [Maniphest] [Commented On] T196165: Commons image: when pasting the exact title, get the correct file first in the suggester

gerritbot added a comment. Change 572616 **merged** by jenkins-bot: [data-values/value-view@master] Put exact matches on top of commons search results https://gerrit.wikimedia.org/r/572616 TASK DETAIL https://phabricator.wikimedia.org/T196165 EMAIL PREFERENCES

[Wikidata-bugs] [Maniphest] [Commented On] T196165: Commons image: when pasting the exact title, get the correct file first in the suggester

Silvan_WMDE added a comment. Added a patch that puts an exact file name match on top of the P‍18 suggester, if there is one in the list of search results. This way, most of the cases described in the ticket should be solved without the need for an additional API call to a second "file name

[Wikidata-bugs] [Maniphest] [Commented On] T196165: Commons image: when pasting the exact title, get the correct file first in the suggester

gerritbot added a comment. Change 572616 had a related patch set uploaded (by Silvan Heintze; owner: Silvan Heintze): [data-values/value-view@master] Put exact matches on top of commons search results https://gerrit.wikimedia.org/r/572616 TASK DETAIL

[Wikidata-bugs] [Maniphest] [Commented On] T196165: Commons image: when pasting the exact title, get the correct file first in the suggester

Silvan_WMDE added a comment. We have in fact considered a toggle for the user to choose between title match and general search, but the result of such considerations was: let's have both at the same time, please. > I'll put this on the agenda for our team meeting next Monday or

[Wikidata-bugs] [Maniphest] [Commented On] T196165: Commons image: when pasting the exact title, get the correct file first in the suggester

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

[Wikidata-bugs] [Maniphest] [Commented On] T196165: Commons image: when pasting the exact title, get the correct file first in the suggester

Silvan_WMDE added a comment. > I don't think it's happening on the search side. I am quite sure it is. Regardless of Wikidata's Javascript code behind the scenes, it is much more instructive to examine the outgoing requests to the commons API

[Wikidata-bugs] [Maniphest] [Commented On] T196165: Commons image: when pasting the exact title, get the correct file first in the suggester

TJones added a comment. > Brilliant answer, thanks for the insights and also for your lovely blog post. Glad to help. I'm always happy to try to figure out what's going on with unexpected search results. > I agree that some kind of extra algorithm must be putting the exact file

[Wikidata-bugs] [Maniphest] [Commented On] T196165: Commons image: when pasting the exact title, get the correct file first in the suggester

Silvan_WMDE added a comment. Brilliant answer, thanks for the insights and also for your lovely blog post . > So, the question is what is the P‍18 search intended to do? Is it supposed to be a general search that can go

[Wikidata-bugs] [Maniphest] [Commented On] T196165: Commons image: when pasting the exact title, get the correct file first in the suggester

Ladsgroup added a comment. In T196165#5864778 , @Silvan_WMDE wrote: > The Property:P18 input box performs a background search via commons API, using the "query" action. That search seems to

[Wikidata-bugs] [Maniphest] [Commented On] T196165: Commons image: when pasting the exact title, get the correct file first in the suggester

Silvan_WMDE added a comment. The Property:P18 input box performs a background search via commons API, using the "query" action. That search seems to be rather fuzzy and returns a list of items ordered by relevance, based on incoming links,

[Wikidata-bugs] [Maniphest] [Commented On] T196165: Commons image: when pasting the exact title, get the correct file first in the suggester

Lea_Lacroix_WMDE added a comment. This issue was mentioned again here , with the case that the correct image doesn't show up at all in the suggester's list. Could we look