Thu, Feb 20
additional changes needed for new wb.api.RepoApi() occurrences in WikibaseLexeme:
Thanks for following up on this. T245589#5896906 also describes how to combine file name prefix search and general search in a single request.
Wed, Feb 19
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:
Tue, Feb 18
Mon, Feb 17
Added a patch that puts an exact file name match on top of the P18 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.
Fri, Feb 14
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.
Thu, Feb 13
I don't think it's happening on the search side.
Wed, Feb 12
Brilliant answer, thanks for the insights and also for your lovely blog post.
Mon, Feb 10
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.
Fri, Feb 7
Thu, Feb 6
deployed and verified:
deployed and verified: link is gone
Wed, Feb 5
Tue, Feb 4
Mon, Feb 3
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.
Wed, Jan 29
Tue, Jan 28
Mon, Jan 27
created github pull request: https://github.com/wmde/WikibaseDataModelServices/pull/233
Jan 24 2020
Jan 23 2020
A change to WikibaseDataModel is needed to avoid some phan error messages triggered when re-enabling the scalar_implicit_cast check.
Jan 22 2020
The progress bar was restored for no apparent reason via https://gerrit.wikimedia.org/r/541001 - is it worth removing the -p switch again?
Jan 21 2020
submitted to the -deploy repo via https://gerrit.wikimedia.org/r/566285
Jan 20 2020
Blocked by T242640
Jan 17 2020
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".
Jan 16 2020
Jan 15 2020
Jan 8 2020
Thanks everyone, I just signed the NDA.