The search on mobile for Wikidata needs to use the entity selector like the desktop version does. Otherwise only page titles are found which are the item ids on WIkidata.
Description
Details
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Jdlrobson | T78430 [Epic] Getting Wikidata to render nicely on mobile web | |||
Resolved | None | T110033 [Story] Redirect users on mobile devices to mobile site automatically | |||
Resolved | Bene | T85368 [Story] Search for Wikidata should give meaningful results on mobile as well | |||
Resolved | Bene | T110069 Make SearchApi module exchangeable | |||
Resolved | Bene | T111209 [Task] Create custom mediawiki search api module | |||
Resolved | thiemowmde | T112865 [Story] Add Wikibase support for PageImages | |||
Resolved | aude | T125396 Config: Enable wbsearch for mobile frontend search on wikidata.org |
Event Timeline
@Bene can you turn your proposal into a patch? That would make it much easier to test and to comment.
Note that this proposal only makes sense if T110069 gets tackled which mainly depends on these two patches: https://gerrit.wikimedia.org/r/233479 and https://gerrit.wikimedia.org/r/233481
I didn't get an answer by @Jdlrobson on my patch yet and he didn't comment on the other one as well.
Current state of this: in the short term we may replace the javascript module to make the search work basically. However, we want to use cirrus search on Wikidata anyways and that would also solve this issue. This is the long term solution which should be used for desktop and mobile search.
@Bene If replacing teh JS module proves to be problematic, we can also provide an API module that wraps sbsearchentities and emulates the output format used by core's title search.
@daniel I also considered that. What about specifying a parameter in wbsearchentities that enables core's search format. This way we can avoid breaking the api output and do not have another module cluttering our api.
@Bene: a separate module would be cleaner, both from the "inside" and the "outside". Adding an option thaqt completely changes the structure of the output is bound to cause confusion, and it leads to multi-option multi-purpose code, which tends to be hard to maintain.
In particular, it's going to be much easier to just remove a module, than to remove an option and clean up the relevant code pathes.
After looking deeper into the search api call, I see that MobileFrontend uses prefixsearch only as a generator and gets all the relevant data via action=query&prop=thumbnail. This makes the whole thing a bit harder. I'm not sure if we want to replicate such a specific query including generators etc. in a fake api. In future however, we should perhaps implement some page props that work for Wikibase entities.
The full query is
{ action: 'query', generator: 'prefixsearch', gpssearch: query, gpsnamespace: this.searchNamespace, gpslimit: 15, prop: 'pageimages', piprop: 'thumbnail', pithumbsize: mw.config.get( 'wgMFThumbnailSizes' ).tiny, pilimit: 15, redirects: '', list: 'prefixsearch', pssearch: query, pslimit: 15 }
Change 234560 had a related patch set uploaded (by Bene):
Create MediawikiSearchEntities api module
Change 234675 had a related patch set uploaded (by Bene):
Allow to use custom displayTitle in search
https://gerrit.wikimedia.org/r/#/c/234560/ isn't finished yet but I want to get some review first to see if the team agrees this is the right way to go. I will create tests and fix jenkins after I got a +1.
Change 238983 had a related patch set uploaded (by Bene):
Configure MobileFrontend to use wbsearch as generator
Change 254645 had a related patch set uploaded (by Bene):
Use custom generator for mobile search on Wikibase
Change 238983 abandoned by Bene:
Configure MobileFrontend to use wbsearch as generator
Reason:
Done in config: https://gerrit.wikimedia.org/r/#/c/254645/1
The only thing for this to be done is getting the config patch merged: https://gerrit.wikimedia.org/r/#/c/254645/ Maybe someone can have a look into that?
Tested this locally, with the following settings:
$wgMFNearby = true; $wgMFQueryPropModules[] = 'pageterms'; $wgMFSearchAPIParams['wbptterms'] = array( 'label' ); $wgMFSearchGenerator = array( 'name' => 'wbsearch', 'prefix' => 'wbs' );
I tested with latest master of core, Wikibase, and MobileFrontend.
I found the following:
- In the search box, I get matches for labels, but labels are not used for display. I just see IDs, no labels or descriptions.
- On Special:Nearby, labels are used for display, but no descriptions are shown.
- Also, I found T119707
- In the search box, I get matches for labels, but labels are not used for display. I just see IDs, no labels or descriptions.
Matched terms will be shown as soon as https://gerrit.wikimedia.org/r/#/c/251207/ is merged.
- On Special:Nearby, labels are used for display, but no descriptions are shown.
I don't know how Special:Nearby works but that is unrelated to this task.
- Also, I found T119707
Perhaps my MobileFrontend patch suffers from the same issues... :S
So, this is blocked on https://gerrit.wikimedia.org/r/#/c/251207/ as far as I can tell.
Do you have the following settings?
$wgMFUseWikibaseDescription = true; $wgMFDisplayWikibaseDescription = true;
descriptions are a separate, general feature that works on any client wiki, including wikidata.
alternatively:
$wgMFSearchAPIParams['wbptterms'] = array( 'label', 'description' );
might work.
- Also, I found T119707
@aude thanks, with the two extra settings, it works as expected.
Still blocked on minor escaping and naming issues in https://gerrit.wikimedia.org/r/#/c/251207/
Patches that need to be merged:
- https://gerrit.wikimedia.org/r/#/c/251207/ (MobileFrontend)
- https://gerrit.wikimedia.org/r/#/c/254645/ (Config)
When done, this can be closed as resolved.
Change 254645 merged by jenkins-bot:
Use custom generator for mobile search on Wikidata