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. See T83609: create script & docs to rename wiki databases and Wiki-Setup (Rename).
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 hreflangattribute
- the textattribute
- the class attribute
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 Github: jeblad/LangCodeOverride.
Prerequisites & expectations
Follows the General prerequisites and expectations.
- Create an extension page at MediaWiki.
Create a help page at MediaWiki. It is probably not necessary for this extension, as it has no user interface component.
- Create an external repo at Github (Github: jeblad/LangCodeOverride) to avoid confusion as an official extension. Move to Gerrit if it become official. (code hosting)
- Create a project entry at Phabricator. This is necessary for the deployment process. Github has issue tracker for the code.
- Create a translate entry at translatewiki.net. This is for localization of the code.
- Prepare for gated deployment.
- Create a role for a mw:MediaWiki-Vagrant instance
- Create sufficient unit tests for the extension.
Describe any changes to the database schema.
- Verify compatibility with other extensions. (In particular Wikibase!)
- Create or somehow host a test version of the extension.
- Get initial code review from some capable developer.
- Get feedback and community support at nowiki. (discussion)
- Get feedback from wikitech-l.
Preparations for deployment
Follows the Preparing for deployment. (Stuff missing.)
- Register a maintainer for the extension at mw:Developers/Maintainers. (Not before initial deployment.)
- Create a task in Phabricator in the Wikimedia-Extension-setup and Wikimedia-extension-review-queue projects to get the extension into the review queue.
- Get a mw:security review and mark the security review as a subtask of the main deployment task.
- Get a product review, if applicable
- Get a mw:design review, if applicable.
Get a mw:beta feature review, if your extension adds a beta feature.
Get a database review, if applicable
- Request deployment to the mw:Beta Cluster
- Make sure the extension is automatically branched by make-wmf-branch
- Request a date/time for deployment