Skip to content

Add BCP 47 redirects for non-standard MediaWiki language codes#498

Open
HakanIST wants to merge 1 commit intowikimedia:masterfrom
HakanIST:fix-nonstandard-bcp47-redirects
Open

Add BCP 47 redirects for non-standard MediaWiki language codes#498
HakanIST wants to merge 1 commit intowikimedia:masterfrom
HakanIST:fix-nonstandard-bcp47-redirects

Conversation

@HakanIST
Copy link
Copy Markdown

MediaWiki core maps several non-standard wiki language codes to standard BCP 47 codes in HTML lang= attributes (via LanguageCode.php). The Universal Language Selector reads these lang attributes but cannot find the BCP 47 codes in the language database, causing those languages to be silently dropped from the Vector 2022 language sidebar.

This adds redirects for the 4 missing BCP 47 codes:

  • jv-x-bmsmap-bms (Basa Banyumasan)
  • nap-x-tararoa-tara (Tarandíne)
  • nrfnrm (Nouormand)
  • ro-cyrl-mdmo (Moldovan)

Bug: https://phabricator.wikimedia.org/T391575

MediaWiki core maps several non-standard wiki language codes to
standard BCP 47 codes in HTML lang= attributes (via LanguageCode.php).
The Universal Language Selector reads these lang attributes but cannot
find the BCP 47 codes in the language database, causing those languages
to be silently dropped from the Vector 2022 language sidebar.

Add redirects for the 4 missing BCP 47 codes:
- jv-x-bms -> map-bms (Basa Banyumasan)
- nap-x-tara -> roa-tara (Tarandíne)
- nrf -> nrm (Nouormand)
- ro-cyrl-md -> mo (Moldovan)

Bug: T391575
@Nikerabbit
Copy link
Copy Markdown
Member

We don't want non-standard codes in language-data.

@HakanIST
Copy link
Copy Markdown
Author

HakanIST commented Apr 23, 2026

Thanks for the quick feedback, @Nikerabbit!

Just to clarify: the codes being added here (nrf, jv-x-bms, nap-x-tara, ro-Cyrl-MD) are actually the standard BCP 47 equivalents, while the existing entries (nrm, map-bms, roa-tara, mo) are the non-standard ones. But I understand if this isn't the right place for the fix.

I also noticed that the ULS rewrite (resources/ext.uls.rewrite/) imports language-data.json directly, bypassing ext.uls.common.js where the alsgsw style redirects live. So a fix only in ext.uls.common.js wouldn't carry over to the new selector.

What would be the preferred approach here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants