daniel added a comment.
In T275251#6947445 <https://phabricator.wikimedia.org/T275251#6947445>, @Jdlrobson wrote: > I understand and I'm saying that this could be implemented using an abstracted PHP interface which provides a contract for the format in the response, without having any knowledge of the implementation. That is possible, but I don't see the point. Why add another layer of indirection in order to make the same endpoint to two different things? > When I mean spec, I'm referring to the output API. The format of the output is one part of the contract. The other part is the relationship between the input and the output, which is defined as "title prefix". To accommodate the Wikibase use case, it would have to be softened to "some kind of match to an identifier of the page" (doesn't have to be the title, but it's not full text either). I'd rather not weaken the contract of the existing endpoint. I'd prefer a separate endpoint, that has a compatible output format. > If an API was created that returned data in the same format, the search UI would mostly function. Yes, mostly. The question is whether that's good enough. I recall that we invested quite a bit of work into getting additional information into the search popup. For example, if I type "تهران" into the search box on wikidata.org, the API responds with entries like this: { "id":"Q643031", "title":"Q643031", "pageid":605069, "repository":"wikidata", "url":"//www.wikidata.org/wiki/Q643031", "concepturi":"http://www.wikidata.org/entity/Q643031";, "label":"Tehran County", "description":"county in Tehran, Iran", "match":{ "type":"label", "language":"ps", "text":"\u062a\u0647\u0631\u0627\u0646 \u0648\u0644\u0633\u0648\u0627\u0644\u06cd" }, "aliases":[ "\u062a\u0647\u0631\u0627\u0646 \u0648\u0644\u0633\u0648\u0627\u0644\u06cd" ] }, Note the "match" and "aliases" keys, and note the rendering of the matched alias in the popup, separate from the disambiguating description, with correct LTR orientation: F34191649: Bildschirmfoto von 2021-03-26 11-32-54.png <https://phabricator.wikimedia.org/F34191649> Extra info like this can be added to the search/title endpoint, the output is extensible. It could also be returned from a separate endpoint. But the UI would also need to use it, that's why I was suggesting a separate UI component. Anyway, assessing the importance of this is up to the Wikidata folks. I'm more concerned with the contract of the `search/title` endpoint. > The implementation can be completely different, living in Wikidata if necessary. Right now, we allow configuration on the host level, but if this is the direction we want to take, we can make the path configurable our side to to support this. For the "same UI, different backend" solution, that would work. The big question is whether Wikidata is OK with "same UI", loosing the extra fatures. TASK DETAIL https://phabricator.wikimedia.org/T275251 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: darthmon_wmde, WMDE-leszek, daniel, sdkim, alexhollender, LGoto, Yair_rand, MPhamWMF, ovasileva, Addshore, Lydia_Pintscher, Aklapper, Jdlrobson, Invadibot, Selby, caldera, maantietaja, Akuckartz, Demian, WDoranWMF, holger.knust, EvanProdromou, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, pmiazga, LawExplorer, Winter, JJMC89, Iniquity, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, Jonas, Volker_E, Niedzielski, Izno, Wikidata-bugs, aude, GWicke, Dinoguy1000, Mbch331, Jay8g
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
