Page MenuHomePhabricator

MUL - Language name of mul language (“multiple languages”) inconsistently used in termboxes
Closed, ResolvedPublic8 Estimated Story PointsBUG REPORT

Description

Steps to reproduce:
Open a Test Wikidata Item with a mul label (and no other labels) using...

What happens?

Desktop:

  • In English, the heading uses the language name “multiple languages”, but the table (once you show “all entered languages”) uses the language name “mul”.
  • In British English, the result is the same.
  • In German, the heading uses the language name „Mehrsprachig“, but the table uses the language name “mul”
  • In mul, the heading doesn’t show a language name (because it’s not a language fallback in this case), but the table uses the language name “multiple languages”.

Mobile:

  • Meanwhile, on mobile, the termbox (mobile termbox, new termbox, termbox v2, etc.) always seems to use “mul” as the language name – except in mul, where you can briefly see the language name “multiple languages” before it gets replaced by JS with just “mul”.

What should have happened instead?

  • In all cases the translated full name (e.g. "multiple languages") should be shown in both the heading and in the table (just as in other languages).
  • We do not have all the usual translations for the "multiple languages" string yet. So if there is no translation, then our standard language fallback chain applies (e.g. to the English "multiple languages" as a last resort).

Notes:

  • Why is the specifically English name “multiple languages” only used when the page is loaded in mul, but not in English itself, nor in any other language?

Acceptance criteria:

  • We understand the problem that leads to this issue.
  • The problem is solved (or if solving the problem is out of scope then please create a follow-up task so we can discuss it).

Original:
John Doe II is a Test Wikidata item with a mul label (and no other labels).

  • In English, the heading uses the language name “multiple languages”, but the table (once you show “all entered languages”) uses the language name “mul”.
  • In British English, the result is the same.
  • In German, the heading uses the language name „Mehrsprachig“, but the table uses the language name “mul”
  • In mul, the heading doesn’t show a language name (because it’s not a language fallback in this case), but the table uses the language name “multiple languages”.

I find this baffling. Why is the specifically English name “multiple languages” only used when the page is loaded in mul, but not in English itself, nor in any other language?

Meanwhile, on mobile, the termbox (mobile termbox, new termbox, termbox v2, etc.) always seems to use “mul” as the language name – except in mul, where you can briefly see the language name “multiple languages” before it gets replaced by JS with just “mul”.

Event Timeline

Manuel changed the subtype of this task from "Task" to "Bug Report".Jul 12 2022, 11:08 AM
karapayneWMDE renamed this task from Language name of mul language (“multiple languages”) inconsistently used in termboxes to MULLANG - Language name of mul language (“multiple languages”) inconsistently used in termboxes.Sep 13 2022, 9:56 AM
karapayneWMDE renamed this task from MULLANG - Language name of mul language (“multiple languages”) inconsistently used in termboxes to MUL - Language name of mul language (“multiple languages”) inconsistently used in termboxes.

Why is the specifically English name “multiple languages” only used when the page is loaded in mul, but not in English itself, nor in any other language?

Because uselang=mul is the only time when that row of the table is rendered server-side in PHP, and then JS just leaves the language name alone. In all other languages, you have to click “all entered languages” to show the mul row, and it’s rendered client-side in JS, where we have different language name data. Specifically, mul is neither included in $.fn.uls.defaults.languages (language names in user language) nor in $.uls.data.languages (autonyms), so the JS code finally falls back to the language code.

Edit: That probably means that if you add mul to your Babel, it’ll use the proper language name all the time, since it’ll always be added to the termbox server-side? I haven’t tested this.

Did some more investigation at T262836#8245640.

Following on from the second part of that (ULS only sends language names for “supported” languages, not all known ones), I propose the following solution:

  • Server-side, we should send the following data:
    • language names for all known languages (LanguageNameUtils::all instead of LanguageNameUtils::supported)…
    • …unless the UniversalLanguageSelector extension is loaded, in which case we leave out all the supported languages (remove them from the array again), to avoid sending those twice
  • Client side (in wikibase.getLanguageNameByCode()), we should use the following sources for the language name, in this order:
    • the language names sent by the Wikibase server-side code above (new!)
    • $.fn.uls.defaults.languages (ULS language names)
    • $.uls.data.languages (ULS autonyms)
    • the language code

This would be a new, generated JSON file in the ResourceLoader module. It’s a bit awkward to “punch out” the majority of the language names just because we happen to know that another extension will send them, but IMHO it’s worth the saved bandwidth.

We should also make the client-side WikibaseContentLanguages service use wikibase.getLanguageNameByCode() instead of only using the ULS language names directly, which would resolve T262836 (benefiting the mobile termbox, and probably monolingual text languages too). Strictly speaking, that’s not part of this task (the classic termbox uses wikibase.getLanguageNameByCode() directly, so it wouldn’t be affected by WikibaseContentLanguages changes), but I expect it to be very little additional effort, so I think it would be a good idea to do it at the same time.

We should also make the client-side WikibaseContentLanguages service use wikibase.getLanguageNameByCode() instead of only using the ULS language names directly, which would resolve T262836 (benefiting the mobile termbox, and probably monolingual text languages too).

Yup, that fixes T275781: Show the language name in monolingual text value's suggester (just tried it out).

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

[mediawiki/extensions/Wikibase@master] Send language names to wikibase.getLanguageNameByCode()

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

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

Change 833397 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Send language names to wikibase.getLanguageNameByCode()

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

Change 833398 merged by jenkins-bot:

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

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