Jdlrobson added a subscriber: Volker_E. Jdlrobson added a comment.
> So we would want to provide a separate API (which you say is fine) Yep new API is fine and the path of least resistance, > So we do not want to confuse things by adding entity search to rest.php/v1/search/title that is specifically meant to search for titles We'd need to make some tweaks to the #WVUI <https://phabricator.wikimedia.org/tag/wvui/> and #Vector <https://phabricator.wikimedia.org/tag/vector/> to allow configuration of the API path. We have wgVectorSearchHost for changing the host, so I'd take care of things that side making sure this configuration evolves to include path. > Can we provide a different API format, that is more generic for a search usecase, rather than one that it tightly bound to MediaWiki concepts? (this would probably need some changes in JS, but probably small ones?) One of the problems with the existing search is we had lots of client code JavaScript specific to Wikibase or configuration code to support Wikibase. For example this code in MobileFrontend: https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/src/mobile.startup/extendSearchParams.js#L28 I really want us to get away from that in the new search by handling this stuff on the server side. I think it would be okay to expand the existing format but I'd rather not deviate too much from it e.g. we should keep the "pages" entry in the response, "title" to mean the search title we display in suggestions, description for description and thumbnail to mean thumbnail. I think it's okay to add new fields though if that's what you mean? WVUI is in control of rendering, so we could expand WVUI to render those additional properties in some way. You'd need to work with the #wvui <https://phabricator.wikimedia.org/tag/wvui/> team (I'd suggest @Volker_E) to incorporate those UI changes but I don't see why not. { "id":3012251, "key":"Q3153277", // label "title":"International Journal of Molecular Sciences", // Description with fallback of the entity description":"peer-reviewed scientific journal", "thumbnail":null // Wikidata specific entry // Add new item to API entry for matched string, which can include fallback, would be one of label, alias, or Qid (item ID) "fallback": }, > Is there a way to add functionality to the search to allow this More expansion bar? There isn't right now. It sounds like this would be a request for a 2nd page of results? The API could be expanded to have a "continue" parameter, and you'd need to talk to @Volker_E and a designer about how that would be incorporated in the UI. My suggestion would be: [ ] 1) current UI searching and displaying labels rather than Q codes [ ] 2) Expand API to include new parameters [ ] 3) Expand WVUI/Vector to support rendering the new optional API data [ ] 4) Add "continue" functionality to API [ ] 5) Expand WVUI to support more functionality. Note new Vector is currently planned for Wikipedias in 2022, but the timeline for Wikidata.org doesn't need to be that. We can make it default when all the above is done. TASK DETAIL https://phabricator.wikimedia.org/T275251 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jdlrobson Cc: Volker_E, Manuel, karapayneWMDE, GreenReaper, R4356th, despens, darthmon_wmde, WMDE-leszek, daniel, sdkim, alexhollender, LGoto, Yair_rand, MPhamWMF, ovasileva, Addshore, Lydia_Pintscher, Aklapper, Jdlrobson, Patafisik_WMF, Invadibot, Selby, caldera, maantietaja, Akuckartz, Demian, WDoranWMF, holger.knust, EvanProdromou, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Winter, JJMC89, Iniquity, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, Niedzielski, Izno, Wikidata-bugs, aude, GWicke, Dinoguy1000, Mbch331, Jay8g
_______________________________________________ Wikidata-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
