[Task] Create custom mediawiki search api module
Closed, ResolvedPublic

Description

While this module will use the same interactor as wbsearchentities it will return results that look like the one obtained by action=query&list=prefixsearch. See T85368#1584395 for more information.

Bene created this task.Sep 2 2015, 4:16 PM
Bene updated the task description. (Show Details)
Bene raised the priority of this task from to Normal.
Bene claimed this task.
Restricted Application added a project: Discovery. · View Herald TranscriptSep 2 2015, 4:16 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Bene updated the task description. (Show Details)Sep 2 2015, 4:20 PM
Bene set Security to None.

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

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

Bene added a comment.Sep 10 2015, 6:51 PM

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).

aude added a subscriber: aude.Sep 14 2015, 4:39 PM

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?

Bene added a comment.Sep 15 2015, 8:39 AM

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

aude added a comment.Sep 15 2015, 9:01 AM

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.

Bene added a comment.Sep 15 2015, 9:04 AM

@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.

aude added a comment.Sep 15 2015, 9:04 AM

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

Bene moved this task from Doing to Review on the Wikidata-Sprint-2015-09-15 board.Sep 17 2015, 5:41 PM
Tobi_WMDE_SW removed Bene as the assignee of this task.Sep 29 2015, 2:01 PM
aude added a comment.Oct 4 2015, 2:51 PM

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.

aude added a comment.Oct 8 2015, 2:25 PM

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

Bene claimed this task.Nov 5 2015, 8:02 AM
Bene moved this task from Backlog to Review on the Wikidata-Sprint-2015-11-03 board.

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

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

Bene closed this task as Resolved.Nov 21 2015, 12:46 PM
Bene moved this task from Review to Done on the Wikidata-Sprint-2015-11-17 board.