additional changes needed for new wb.api.RepoApi() occurrences in WikibaseLexeme:

• resources/special/NewLexeme.js
• resources/view/ControllerViewFactory.js
• resources/widgets/LexemeHeader.js

Thanks for following up on this. T245589#5896906 also describes how to combine file name prefix search and general search in a single request.

Conveniently, the first of the two example requests from the mobile app demonstrates how to combine both the file name prefix search and the general search in a single request:

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 matcher" endpoint. Note that an exact file name match will still not show up on top, if it is not included in the list of top 10 search results, served by the commons 'query' API action.

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 don't think it's happening on the search side.

Brilliant answer, thanks for the insights and also for your lovely blog post.

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, templates, language etc. Apparently there is no easy configuration of request parameters (such as srqiprofile, srwhat, srsort, ...) that puts exact title matches on top of the returned list, while leaving the fuzzy search results in. However, exact string search is supported and the user can easily work around the issue by wrapping their "search string" in double-quotes.

deployed and verified:

deployed and verified: link is gone

Moved stub changes from https://gerrit.wikimedia.org/r/568470 to separate patch https://gerrit.wikimedia.org/r/569550, so that they can be merged independently from the (currently still failing) phan config change.

The two related patch sets do not fix the issue described in this task, they only add unit tests to cover the required changes. Fixing the issue will include enhancing WikibaseLexeme's forms and senses with metadata that are currently hard-wired into Wikibase's ResultBuilder. This looks complex and is probably out-of-scope for the task described here.

created github pull request: https://github.com/wmde/WikibaseDataModelServices/pull/233

A change to WikibaseDataModel is needed to avoid some phan error messages triggered when re-enabling the scalar_implicit_cast check.

The progress bar was restored for no apparent reason via https://gerrit.wikimedia.org/r/541001 - is it worth removing the -p switch again?

submitted to the -deploy repo via https://gerrit.wikimedia.org/r/566285

Blocked by T242640

Apparently, the disabled checks have all been removed from the config file since this task was created, but just recently libraryupdater changed it again for being "too spammy".

Thanks everyone, I just signed the NDA.