Page MenuHomePhabricator

Expose more language data through the API
Open, Needs TriagePublic

Description

The language data used by mw.language is currently only for the wgUserLanguage (exported by ResourceLoaderLanguageDataModule.php). This limits the ability to add i18n/l10n support for gadgets and user scripts that are used for editing, since edits should be made in the wgContentLanguage of the wiki.

The language data (digitTransformTable, grammarTransformations, pluralRules, etc) are not accessible even using the API. An API endpoint should be created to expose this data.

Event Timeline

ApiQueryLanguageInfo is related. Would it be acceptable to expand this API to also provide the i18n rules data?

Along with that, i18n tools such as mw.language and jquery.18n should give a choice between using wgUserLanguage or wgContentLanguage, rather than always using wgUserLanguage.

Seems like a seperate request

Reedy renamed this task from Expose language data through an API endpoint to Expose more language data through the API.Dec 30 2020, 8:29 PM
Reedy removed a project: JavaScript.

Along with that, i18n tools such as mw.language and jquery.18n should give a choice between using wgUserLanguage or wgContentLanguage, rather than always using wgUserLanguage.

Seems like a seperate request

Removed.

Change 693214 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/core@master] Expose additional language data through ApiQueryLanguageinfo

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

Currently the banana-i18n library does provide a way to do i18n in non-wgUserLanguage. However, the limitation is that it bundles a large amount of data (like fallbacks.json) for all possible languages. A more efficient approach that reduces the bundle size would be to use a library that makes optimally cached requests to fetch the language data only for the language(s) needed. Exposing the language data through the API would be the first step towards writing such an i18n library.

For client-side use cases (i.e. not separate PHP/Python/Node.js tools that consume the MW API, but gadgets), I would recommend Intl API instead. This has gotten pretty good in modern browsers, and would be even better than requiring async downloads from the MW API.

The proposed patch exposes internals of the MW language data, but I'm not sure how stable that is long-term to expose in that exact way. It's also not very usable by itself as API consumer as you'd need fairly elaborate parsers for it, and packages for that tend to come with their own data already.

Intl is also available in Node.js built-in.

Change #1280807 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/core@master] Expose pluralrules through ApiQueryLanguageinfo

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

Change #693214 merged by jenkins-bot:

[mediawiki/core@master] Expose additional language data through ApiQueryLanguageinfo

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