Page MenuHomePhabricator

WikibaseContentLanguages names not available in client
Closed, ResolvedPublicBUG REPORT


Steps to Reproduce:

Open as anonymous user

Actual Result:

Some languages (e.g. fkv, dag, ...) are only shown as codes, not using their names.

Languages (e.g. fkv, dag, ...), which are WikibaseContentLanguages, i.e. added to the list of MediawikiContentLanguages, don't seem to be (consistently?) available in the client side equivalent wikibase.WikibaseContentLanguages.js - the client-side service definiton as used in termbox.

(new window.wb.WikibaseContentLanguages()).getAllPairs()

yields an empty result and termbox falls back to showing the language code only.

The server-side implementation (via wbcontentlanguages) successfully gets to the language names however. This can be witness by opening the example and quickly looking at the termbox before client-side rendering replaces it.

Expected Result:

All valid content languages are shown using their name.


This was discovered when researching T261851.

The fallback to show the language code in case of unknown languages was implemented as part of T217770.

Non-standard languages are a recurring topic for termbox. T231007 or T214969 may have overlap with the current topic.

Event Timeline

I think there are two related problems here:

  1. Wikibase client-side code has two different ways to look up language names. wikibase.getLanguageNameByCode() uses $.fn.uls.defaults.languages (language names) and $ (autonyms); WikibaseContentLanguages.js uses mw.config.get( 'wgULSLanguages' ) (language names, ultimately the same as $.fn.uls.defaults.languages). There are currently 215 language codes that are available as autonyms but not language codes, and which WikibaseContentLanguages.js therefore misses; I haven’t checked how many of them are content languages of any kind, though.
  1. The language names at $.fn.uls.defaults.languages / mw.config.get( 'wgULSLanguages' ) (same thing) are missing some language names that we might be interested in, because ResourceLoaderUSLModule::getData() fetches language names for “supported” languages ('mwfile' = LanguageNameUtils::SUPPORTED), which are “the languages for which we have at least some localisation”. That’s fine for the ULS use case, but a bit of a problem when we want to use the same language data in the termbox where “unsupported” language codes may still be used.

(The autonyms at $ are in extensions/UniversalLanguageSelector/lib/jquery.uls/src/, hard-coded into the JS source code, technically completely independent from any other language data in MediaWiki. I can only hope that they’re kept in sync somehow – the file seems to receive regular Git commits, at least.)

(new window.wb.WikibaseContentLanguages()).getAllPairs()

That’s an incorrect way to use the class, by the way, and nowadays it throws in that case. But it’s still a problem that the language maps returned by


include some undefined values (no language name known).

Change 833398 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] Use wb.getLanguageNameByCode() in WikibaseContentLanguages

Change 833398 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Use wb.getLanguageNameByCode() in WikibaseContentLanguages

Lucas_Werkmeister_WMDE claimed this task.

I’m going to close this directly, considering it a tech task. The following two expressions return nonempty arrays on Wikidata (fix not deployed yet), but empty arrays on Beta Wikidata:

Object.entries(wb.WikibaseContentLanguages.getTermLanguages().getLanguageNameMap()).filter(([k,v]) => v === undefined).map(([k,v]) => k)
Object.entries(wb.WikibaseContentLanguages.getMonolingualTextLanguages().getLanguageNameMap()).filter(([k,v]) => v === undefined).map(([k,v]) => k)