WikibaseContentLanguages names not available in client
Closed, ResolvedPublicBUG REPORT
Actions

Assigned To

Authored By

	• Pablo-WMDE
	Sep 14 2020, 5:24 PM

Description

Steps to Reproduce:

Open https://m.wikidata.org/wiki/Q4115189?uselang=fkv 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.

Meta:

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.

Details

	Subject	Repo	Branch	Lines +/-
	Use wb.getLanguageNameByCode() in WikibaseContentLanguages	mediawiki/extensions/Wikibase	master	+11 -24

Customize query in gerrit

Related Objects

Mentioned In: T311626: MUL - Language name of mul language (“multiple languages”) inconsistently used in termboxes
T286031: add language name "Latin American Spanish" for code "es-419" to LocalNamesEn.php
Mentioned Here: T214969: Investigate where fallback languages come from [8h]
T217770: [Story] Never show anything from a language that is not currently Wikidata conform
T231007: Handle unsupported languages more gracefully
T261851: Language in Wikidata termbox shows native language names (samples: es-419, sms, nod) or language code (samples: srq, en-us) instead of localised names for some languages

Event Timeline

• Pablo-WMDE created this task.Sep 14 2020, 5:24 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 14 2020, 5:24 PM

• Pablo-WMDE added a subscriber: Lydia_Pintscher.Sep 14 2020, 5:24 PM

Lydia_Pintscher added a project: Wikidata-Campsite.Sep 14 2020, 6:06 PM

Restricted Application added a project: Wikidata. · View Herald TranscriptSep 14 2020, 6:06 PM

Esc3300 added a project: Language codes.Jul 20 2021, 8:11 AM

Esc3300 moved this task from Backlog to Wikidata (termbox languages) on the Language codes board.

Esc3300 mentioned this in T286031: add language name "Latin American Spanish" for code "es-419" to LocalNamesEn.php.Jul 20 2021, 8:57 AM

Raymond subscribed.Jul 20 2021, 9:05 AM

Lydia_Pintscher mentioned this in T311626: MUL - Language name of mul language (“multiple languages”) inconsistently used in termboxes.Jul 12 2022, 10:09 AM

Manuel moved this task from Incoming to Miscellaneous on the Wikidata-Campsite board.Jul 12 2022, 12:05 PM

I think there are two related problems here:

Wikibase client-side code has two different ways to look up language names. wikibase.getLanguageNameByCode() uses $.fn.uls.defaults.languages (language names) and $.uls.data.languages (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.

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 $.uls.data.languages are in extensions/UniversalLanguageSelector/lib/jquery.uls/src/jquery.uls.data.js, 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

wb.WikibaseContentLanguages.getTermLanguages().getLanguageNameMap()
wb.WikibaseContentLanguages.getMonolingualTextLanguages().getLanguageNameMap()

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

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

gerritbot added a project: Patch-For-Review.Sep 20 2022, 3:02 PM

Change 833398 merged by jenkins-bot: