Some projects has been configured with erroneous language codes, and the situation is quite annoying. A complete fix of the root case imply moving the projects, which are not feasible without automated processes. That is scripts must be made, and running them could imply serious downtime.
As a temporary stop gap measure the language links in the sidebar can be fixed with an extension. Such an extension should at least fix
- the `lang` attribute
- the `hreflang`attribute
- the `text`attribute
- the `class` attribute
An extension like this is described as solution number 4 by @tstarling in post T174160#3798644
> Hook `SkinTemplate::getLanguages()` to determine the site being linked to, and implement a special case for nowiki which uses the "nb" autonym for the "no" language code.
A core problem is how to make a reasonably small config, as only some projects has language codes that are wrong. For example, Wikipedia has a project where "no" is used and interpreted incorrectly as "nb", while Wikisource has a project where "no" is used correctly. Overriding "no" everywhere will be wrong, but overriding only on dbnames will create a huge configuration file. A simple workaround would be to extract the group from SiteLookup by using `$wgDBname`, and make a two-level configuration. The extension uses this approach.
The proof of concept is at [[https://github.com/jeblad/LangCodeOverride|Github: jeblad/LangCodeOverride]].
- [X] create a rough barebone extension
- [X] create a documentation entry at MediaWiki
- [ ] create a project entry at Phabricator
- [X] create a translate entry at translatewiki.net
- [ ] complete unit testing
- [ ] change from Grunt to Composer
- [ ] someone to decide if this is an acceptable solution (?)
- [ ] attempt a test at beta cluster