Change 234560 had a related patch set uploaded (by Bene):
Create MediawikiSearchEntities api module

https://gerrit.wikimedia.org/r/234560

As promised, here is a summary of what the needs of both the Wikidata and the Mobile team are:

Mobile

• only replace api call, no further javascript adjustments (preferable via a hook?)
• currently using list=prefixsearch&generator=prefixsearch -> other api call should have same result format

Wikidata

• show the term that matched as the link text (may be the label, an alias or the id)
• for now use the same lookup service as wbsearchentities
• nice to haves:
  • show description of the item below its label
  • show a thumbnail based on P18

Conclusion

What comes into my mind is to provide a custom list=wikidatasearch&generator=wikidatasearch instead of a completely new api module. This way we can avoid to fale the whole response structure and the module gets more reusable. Furthermore, this option is more likely to fit our future needs for using Elastic as Wikidata's search engine (T88534).

To fix the problem of displaying the correct title, the mobile search code would need some tweaks for this solution because currently it doesn't take the title from the list=prefixsearch result but from the prop=pageimages information. This should however be trivial to fix. This system could also be extended to show a redirect's title instead of the target's title when matching a redirect (other story though).

I think we can hook into PrefixSearch to have it produce relevant results for content such as Wikibase content.

right now it (usually) returns a list of titles, but there also is a (not totally nice, but could be useful) SearchResult thing in core. Maybe that could be used in PrefixSearch and be extended to have something like getDisplayText or such.

with this, then already we can get both existing api calls (the one used for mobile and the opensearch one) to return results for Wikibase, based on term search. (using EntitySearchHelper)

This somewhat easily works with the default search backend (db), though need to think how to have this also work when Cirrus is enabled.

Does https://gerrit.wikimedia.org/r/#/c/234730/ provide what you need on the frontend?

@Jdlrobson I've commented there. I think this will work for our needs so far. :-)

in the short term, I think substituting the api call can work, but would like the core prefix search mechanism to just support content such as Wikibase items where the desired display text is different than the title text.

@aude yes, that's the long term solution but I guess it will need a "bit" more work to make that happen. Only getting wikidata terms into Cirrus is already non-trivial afaik.

In T111209#1627047, @Bene wrote:

What comes into my mind is to provide a custom list=wikidatasearch&generator=wikidatasearch instead of a completely new api module. This way we can avoid to fale the whole response structure and the module gets more reusable. Furthermore, this option is more likely to fit our future needs for using Elastic as Wikidata's search engine (T88534).

do we want this to be wikibasesearch instead of wikidatasearch?

sounds like this is a non-temporary solution which could be ok. Supporting generators seems like a nice idea.

To fix the problem of displaying the correct title, the mobile search code would need some tweaks for this solution because currently it doesn't take the title from the list=prefixsearch result but from the prop=pageimages information. This should however be trivial to fix. This system could also be extended to show a redirect's title instead of the target's title when matching a redirect (other story though).

Change 238771 had a related patch set uploaded (by Bene):
Create wbsearch api query module

https://gerrit.wikimedia.org/r/238771

Change 234560 abandoned by Bene:
Create MediawikiSearchEntities api module

Reason:
In favour of https://gerrit.wikimedia.org/r/#/c/238771/

https://gerrit.wikimedia.org/r/234560

Special:Nearby has some of the same issues as mobile search, in that the title text (e.g. Q64) is displayed by default. It uses geosearch as the generator instead of prefixsearch, but otherwise is mostly the same api call.

What we might want to do is have displaytext as a pageprop? then it could easily be used in both places and be a generic thing.

though that doesn't solve the problem that prefix search doesn't find anything meaningful from Wikibase content.

see also T115014 and T115013 which involve related issues and ideally the solution could work for all these use cases

Change 238771 merged by jenkins-bot:
Create wbsearch api query module

https://gerrit.wikimedia.org/r/238771