Addshore added a comment.
Hi @Jdlrobson So initially highlighting what is currently displayed in our results 1. Label of matched entity with fallback in user language 2. Matched string, which can include fallback, would be one of label, alias, or Qid (item ID) 3. Description with fallback of the entity F34644686: image.png <https://phabricator.wikimedia.org/F34644686> > The main blocker for this is having a functioning search API that returns results for queries such as https://wikidata.org/w/rest.php/v1/search/title?q=Q3&limit=10. It's also acceptable for Wikidata to provide its own API if that is preferred - the search API is configurable and we can point to any service you want to, provided the response is consistent with that APIs specification. 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, the functionality there should remain the same and just be provided by MediaWiki, as also expressed by daniel in T275251#6944581 <https://phabricator.wikimedia.org/T275251#6944581>, this would break the contract. So we would want to provide a separate API (which you say is fine) However we don't really want to have to provide an API response that is again confusing if people were to ever look at it (with title etc). Is there some way we could provide some sort of API adapter or a second format that this JS code can deal with? Taking inspiration from https://www.mediawiki.org/wiki/API:REST_API/Reference#Search_result_object We would want to return: - **Page title**, or just **URL to link to** for the result. Thinking ahead for possible future cases we may want to consider, URL would be preferred - **Display line 1** - Which in our case would be something like `LABEL (MATCH)` where LABEL is a fall back enabled label for user display and MATCH is the string that actually matched, if different from that label - **Display line 2** - This would be our description with language fallback - **Image url** - We wouldn't provide this initially, but would want to in the future, and would ideally like to hide the image doesn't exist part of the result But we don't want to introduce a confusing situation of miss using the API, or format. Perhaps this is even something that should change in the main REST spec? The other key part of the experience that we don't want to loose is the `More` bar. F34644680: image.png <https://phabricator.wikimedia.org/F34644680> Clicking this expands the existing results without navigating to another page F34644682: image.png <https://phabricator.wikimedia.org/F34644682> So some concrete questions: 1. 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?) 2. Is there a way to add functionality to the search to allow this `More` expansion bar? TASK DETAIL https://phabricator.wikimedia.org/T275251 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore Cc: 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, Volker_E, Niedzielski, Izno, Wikidata-bugs, aude, GWicke, Dinoguy1000, Mbch331, Jay8g
_______________________________________________ Wikidata-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
