Page MenuHomePhabricator

Keys should be displayed as labels in chosen language
Closed, ResolvedPublic

Description

The display of a key should use the label in the user language when being displayed.

Event Timeline

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

DVrandecic triaged this task as Lowest priority.Nov 24 2020, 7:11 PM
DVrandecic raised the priority of this task from Lowest to Low.
DVrandecic moved this task from To triage to Phase β on the Abstract Wikipedia team board.

Change 643568 had a related patch set uploaded (by Gabrielchihonglee; owner: Gabrielchihonglee):
[mediawiki/extensions/WikiLambda@master] Show key labels in user langauge

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

DVrandecic raised the priority of this task from Low to Medium.Dec 4 2020, 10:28 PM

Follow-ups:

Change 643568 merged by jenkins-bot:
[mediawiki/extensions/WikiLambda@master] Show key labels in user language

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

  • Should use server-side language resolution rather than doing the work locally.

For this, maybe there should be another task for un-hard-coding the key labels.

@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:

api.php?action=query&format=json&list=wikilambda_searchlabels&wikilambda_language=es&wikilambda_limit=5000

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.

Change 654513 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/WikiLambda@master] ApiQueryZObjectLabels: Allow for language fallback searching, default on

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

Change 654513 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/WikiLambda@master] ApiQueryZObjectLabels: Allow for language fallback searching, default on

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

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.

Change 654513 merged by jenkins-bot:
[mediawiki/extensions/WikiLambda@master] ApiQueryZObjectLabels: Allow for language fallback searching, default on

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

DVrandecic raised the priority of this task from Medium to High.Jan 6 2021, 5:47 PM

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.

Change 654885 had a related patch set uploaded (by Genoveva Galarza; owner: Genoveva Galarza):
[mediawiki/extensions/WikiLambda@master] Handle user language from the state and display labels in user language

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

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,

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.

Change 654885 merged by jenkins-bot:
[mediawiki/extensions/WikiLambda@master] Handle user language from the state and display labels in user language

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