The display of a key should use the label in the user language when being displayed.
There is currently an API that can provide the labels for a given Z-Object in a given language. This can be called and cached locally (so that we don't ask for each of the four keys of a given Z-Type individually).
This can be used to display the labels of the keys in the given language.
API name: APIZObjectFetcher
- Should use mw.Api so that it works on servers with non-default URL layout.
Should have a cache to fetch things only once.-> T270301: Minimize the times OtherKeys component calls wikilambda_fetch; create a global state manager?
- Should use server-side language resolution rather than doing the work locally.
@Jdforrester-WMF I am using wikilambda_searchlabels to get the labels in the user defined language, but somehow the language fallback doesn't seem to be working for me. For example:
will only return for me the zObjects that have labels in Spanish.
Is this the expected behavior? Or should I expect the available labels to be returned in Spanish and the rest to be returned in English?
Ah, right, yes, there's no language fallback in ApiQueryZObjectLabels (wikilambda_searchlabels). There is for ApiZObjectFetcher (wikilambda_fetch), which is what I expected you to use and tested. :-)
Adding fallback language support to the former is conceptually not that easy; I'll rustle up a quick patch, but we should talk.
OK, with this patch api.php?action=query&format=json&list=wikilambda_searchlabels&wikilambda_language=es&wikilambda_limit=50 will return labels for everything that has at least a label in 'es' or 'en'; see the page_language key for which it's in. api.php?action=query&format=json&list=wikilambda_searchlabels&wikilambda_language=als&wikilambda_limit=50 will look for labels in 'als', 'gsw', 'de', and 'en'.
If you want strict language equality, you can either filter client-side (based on page_language, if e.g. you want a "show other language results" in a searcher), or append &wikilambda_nofallback=1 to the query.
You are right, for the key labels it should not be necessary to request anything to wikilambda_searchlabel, although we will need it for the type/zobject selector anyway, so thanks!!
I am however finding that with the wikilambda_fetch API I am always being returned all the available languages for the keys, so when I request api.php?action=wikilambda_fetch&format=json&zids=Z3&language=es
I am getting the same response as If I queried api.php?action=wikilambda_fetch&format=json&zids=Z3, so on the front-end we need to loop through all the languages and select the appropriate one. I understood that by passing language as a parameter, we could get the information on the given language and, if unavailable, on the fallout one. Did I have the wrong understanding?. I also tried with the uselang=es parameter, with the same result.
Ah, yes, wikilambda_fetch is for fetching entire ZObjects, including all the data of all their keys; it only filters languages in the top-level Z2K3 currently. We could walk the object, but we currently don't.
I checked jquery.i18n as suggested but I couldn't find a way to use it for our benefit. However, navigating a bit on codesearch I saw that few projects use mw.language.getFallbackLanguageChain() to get the array of the language fallback chain. I finally used this in the strategy to decide which label to display.
As a final fallback, if none of the languages in the fallback chain are found, it will display whatever human-readable label is firstly available.