Page MenuHomePhabricator

Define and implement new API action to replace the internal use of wikilambda-fetch
Closed, ResolvedPublic

Description

wikilambda-fetch is meant to give a stable interface to access a ZObject from the outside. Because of that it uses some escaping mechanism that makes it not play nicely with tools such as the API Sandbox.

We need to define an API action that makes it easy for the WikiLambda front end to make requests to the MediaWiki backend.

Event Timeline

DVrandecic triaged this task as Medium priority.Feb 3 2021, 5:50 PM

Current components that use wikilambda_fetch API:

  • ZObjectEditor
    • Fetches Z1 to capture the bottom level labels necessary to display the editor of a new ZObject type (Z1K1)
  • ZObjectKeyList
    • Fetches the ZID parent of the keys, and the ZIDs that correspond to the key types, to display their labels in the correct language
  • ZObjectSelector
    • If a ZID is directly input into a ZObjectSelector, it fetches it to check that: 1) it exists, and 2) it's of the valid type.
  • ZObjectGeneric
    • When the type is assigned or updated, it fetches the ZID to gather its keys and add them into the ZObjectKeyList component.
    • Fetch information of ZID and its keys in case it's not yet available, to display the labels in the appropriate language.

In summary:

Apart from the initial full ZObject, which comes directly from the PHP back-end, in the current implementation we only query wikilambda_fetch to:

  1. Get the labels in the user preferred language. This seems quite expensive: We are getting full ZObjects, from where we need to extract simply the labels, which adds complexity and affects performance. E.g. We want the labels necessary for the key Z2K3, for which we request Z2 and Z12, store them fully and also store their labels in the zKeyLabels state variable.
  2. Get the keys of a given ZID to populate the ZObjectKeyList when we create a ZObject

Current caveats of wikilambda_fetch:

  • Not currently returning a JSON object
  • If wikilambda_fetch language parameter is not specified, it will return all the languages available.
  • If the language is specified, but is not available:
    • ZID label will return No label defined in this language or accepted fallbacks
    • ZKeys labels return all the languages available.
  • If a set of ZIDs are requested, and one of them does not exist, it will return an error for the whole request, ignoring the ZIDs that do exist.

Current front-end wishlist would be to have:

  • Default behavior: Ask the API to return the whole ZObjects, with all the labels in different languages, etc. This will not be needed now, but could be in the future if we want to request and editable ZObject via API instead of bringing it from the PHP backend. If we want to have independent components, this will be necessary.
  • Request the API to return everything but limited to one language. This way we don't need to navigate all the language labels in the front-end and select one depending on the language fallback chain, which would be an improvement considering that, in the future, a ZObject can have n keys, and each key have labels in hundreds of different languages.
    • ZID label will be in requested language or fallbacks
    • ZKey labels also in requested language or fallbacks
  • On requested a set of ZIDs, return an array where each ZID can be either the requested ZObject or a Z5 (Error) representing that the given ZID is not found.

To fullfil the wishlist, the request parameters could be something like:

  • zids List of zids separated by |
  • raw Returns a list of raw and valid ZObjects, with all labels in all languages. This should be a JSON object that could be plugged into the root component and be viewed or edited.
  • language If raw=false, returns a list of language-aware ZObjects, where every ZMultilingualString is just one element with the selected language depending on the user's preferred language and its fallback chain.
DVrandecic renamed this task from Define new API action to replace the internal use of wikilambda-fetch to Define and implement new API action to replace the internal use of wikilambda-fetch.Feb 10 2021, 5:29 PM

Should we split the second bullet into a different API that's single-language-specific and walks the tree entirely to reduce Z12s to a single label, not just the top-level Z2K3?

Change 664558 had a related patch set uploaded (by Genoveva Galarza; owner: Genoveva Galarza):
[mediawiki/extensions/WikiLambda@master] Add query API wikilambda_zobjects to fetch ZObjects for internal use.

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

Change 664559 had a related patch set uploaded (by Genoveva Galarza; owner: Genoveva Galarza):
[mediawiki/extensions/WikiLambda@master] Add i18n English texts for the wikilambda_zobjects query API and Spanish translations

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

Change 664559 abandoned by Genoveva Galarza:
[mediawiki/extensions/WikiLambda@master] Add i18n English texts for the wikilambda_zobjects query API and Spanish translations

Reason:
Moving messages to previous commit and dropping Spanish translations

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

Change 664558 merged by jenkins-bot:
[mediawiki/extensions/WikiLambda@master] Add query API wikilambda_zobjects to fetch ZObjects for internal use.

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