Tarandíne, Nouormand and Basa Banyumasan

What is special is they used non-standard language codes.

@santhosh, @KartikMistry, @Nikerabbit, as you are members of the UniversalLanguageSelector team, is there anything I can do to help get this issue triaged? This seems to be a critical problem.

I debugged a bit around and I found the cause:
The list in jquery.uls.data.js includes the language codes from the URLs, but mw.uls.getInterlanguageListFromNodes() uses the "lang" attribute of the non-ULS links to find the entries in that list.
So the solution is to fix that list to use the proper lang codes (which should follow ISO-639(?)).

I looked a bit around and think the differing "lang" values are coming from this LanguageCode.php. For the "deprecated" codes we already have both variants in jquery.uls.data.js, so it's only the "non-standard" list where we need to add the corresponding standard codes to jquery.uls.data.js.

I'm just seeing that all changes to jquery.uls.data.js say "Update from upstream". Where is upstream for this file?

In T391575#11827378, @Wickie37 wrote:

I'm just seeing that all changes to jquery.uls.data.js say "Update from upstream". Where is upstream for this file?

It comes from language-data. See https://www.mediawiki.org/wiki/Manual:Adding_and_removing_languages#jquery.uls

In T391575#11827907, @Bugreporter wrote:

In T391575#11827378, @Wickie37 wrote:

I'm just seeing that all changes to jquery.uls.data.js say "Update from upstream". Where is upstream for this file?

It comes from language-data. See https://www.mediawiki.org/wiki/Manual:Adding_and_removing_languages#jquery.uls

Thanks!
I had another look into LanguageCode.php. We only need to care about the codes that represent wikis, not the "-formal" stuff etc. This reduces the list to the following 6 codes that need to be changed:

'cbk-zam'  => 'cbk'
'eml'      => 'egl'
'map-bms'  => 'jv-x-bms'
'mo'       => 'ro-Cyrl-MD'
'nrm'      => 'nrf'
'roa-tara' => 'nap-x-tara'

Though I'm not sure whether we need to keep the non-standard codes as redirects.

Thanks for the great debugging work here, @Wickie37 and @Bugreporter!

I took a closer look and can confirm the root cause. Of the 6 codes listed, only 4 are actually broken. cbk and egl already exist as full entries in language-data, so cbk-zam and eml resolve fine. The broken ones are:

There's already a precedent for this in ext.uls.common.js: als is redirected to gsw via $.uls.data.addLanguage(). Adding similar redirects for these 4 codes should fix the issue.

In T391575#11850225, @HakanIST wrote:

There's already a precedent for this in ext.uls.common.js: als is redirected to gsw via $.uls.data.addLanguage(). Adding similar redirects for these 4 codes should fix the issue.

Considering T414588: Alemannic German (als) articles missing from language selector it might be possible that this doesn't fix the issue entirely.

In T391575#11854203, @Johannnes89 wrote:

Considering T414588: Alemannic German (als) articles missing from language selector it might be possible that this doesn't fix the issue entirely.

I looked into the iOS app source and the root cause there is slightly different. There's no gsw→als mapping in languageCodeForISOLanguageCode: (only nb→no exists), so the language silently drops.

Update: My earlier claim about the ULS rewrite bypassing ext.uls.common.js was misleading. The critical path where languages get dropped still goes through getInterlanguageListFromNodes() and $.uls.data.isRedirect(), so adding redirects in ext.uls.common.js (like the existing als/gsw pattern) should fix the core issue.

Change #1280166 had a related patch set uploaded (by HakanIST; author: HakanIST):

[mediawiki/extensions/UniversalLanguageSelector@master] Add BCP 47 redirects for non-standard MediaWiki language codes

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

Change #1280166 merged by jenkins-bot:

[mediawiki/extensions/UniversalLanguageSelector@master] Add BCP 47 redirects for non-standard MediaWiki language codes

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