Page MenuHomePhabricator

LangCodeOverride: Extension to override language codes in the sidebar
Closed, DeclinedPublic

Assigned To
Authored By
jeblad
Nov 8 2018, 7:03 PM
Referenced Files
F27229237: Screenshot-LangCodeOverride-2018-11-15.png
Nov 15 2018, 10:51 AM
Tokens
"Like" token, awarded by Danmichaelo."Love" token, awarded by Liuxinyu970226."Love" token, awarded by jhsoby."Love" token, awarded by Soulkeeper.

Description

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

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.

Screenshot-LangCodeOverride-2018-11-15.png (569×878 px, 50 KB)

The proof of concept is at Github: jeblad/LangCodeOverride.

Prerequisites & expectations

Follows the General prerequisites and expectations.

Preparations for deployment

Follows the Preparing for deployment. (Stuff missing.)

Event Timeline

jeblad updated the task description. (Show Details)

@jeblad regarding your

Create a project entry at Phabricator. This is necessary for the deployment process. Github has issue tracker for the code.

As I pointed at T209231, it's unlikely happened for a Github maintained extension unless if you agree to submit a request at Gerrit/New_repositories/Requests to move them back to under WMF version control system.

Do you still need this?

jeblad changed the task status from Open to Stalled.EditedNov 17 2018, 4:30 PM

Seems like this is stalled on community consensus at nowiki. Pick it up later if (and when) consensus emerge, or other communities want it implemented.

Change 474482 had a related patch set uploaded (by John Erling Blad; owner: John Erling Blad):
[mediawiki/vagrant@master] Added role for extension LangCodeOverride

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

jeblad updated the task description. (Show Details)

Unit tests gives

OK (24 tests, 84 assertions)

Running whole set before adding extension gives

Tests: 20854, Assertions: 136094, Failures: 4, Skipped: 45.

Adding extension gives

Tests: 20879, Assertions: 136179, Failures: 8, Skipped: 45.

Bugger!

Change 474482 merged by jenkins-bot:
[mediawiki/vagrant@master] Added role for extension LangCodeOverride

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

Verified coexistence with Wikibase, which is ok.
Have not verified whether there were changes in reported errors from tests.

Wikibase started as (MediaWiki-Vagrant#wikidata, Wikibase/Installation#Vagrant, Wikibase/Installation#Run the setup scripts)

mkdir lcospace3
cd lcospace3
git clone --recursive https://gerrit.wikimedia.org/r/mediawiki/vagrant .
./setup.sh
vagrant up # destroy, update and recreate if box is outdated
vagrant git-update
vagrant ssh
sudo apt-get update
sudo apt-get upgrade
composer selfupdate --update-keys
composer config --global process-timeout 9600
exit
vagrant reload # may need a reload due to apt-get upgrade
vagrant roles enable wikidata
vagrant provision # here be errors, T211611, it fails on every odd run
vagrant git-update
vagrant provision
vagrant git-update
vagrant ssh
cd /vagrant/mediawiki
mwscript extensions/Wikibase/client/maintenance/populateInterwiki.php --wiki=wikidatawiki
mwscript extensions/Wikibase/lib/maintenance/populateSitesTable.php --wiki=wikidatawiki
mwscript extensions/Wikibase/client/maintenance/populateInterwiki.php --wiki=enwiki
mwscript extensions/Wikibase/lib/maintenance/populateSitesTable.php --wiki=enwiki
exit
vagrant reload
vagrant roles enable langcodeoverride
vagrant provision
vagrant git-update
nano mediawiki/extensions/LangCodeOverride/extension.json # change group "wiki" to "wikipedia"
vagrant reload

Create a minimal article for "Norway" at enwiki:Norway, then click [Add links] to navigate to wikidatawiki, fill in the necessary data, and create the item. Then go back to enwiki:Norway, open it for editing, and save again to force reparsing.

If everything is correct, then the link in the sidebar should be "Norsk bokmål" and not "Norsk".

I have double checked and the script above should be complete.

There are community consensus for changing the sidebar, a very weak consensus for changing the entry in the site matrix, and no consensus for any changes in the prefix. The later discussion is very confusing with people arueing against their own voting. My proposal was to delay any changes because I doubt it was possible to get consensus for anything else. It triggered fierce resistance, which was opposite of the recommendation, but it seems like the users read it as an opposite recommendation.

Seems like the consensus is to use the extension with the present functionality; w:no:Wikipedia:Tinget#Synlig språkkode. Still, any changes are blocked due to the resistance from a few editors.

I'm going to leave this task as "stalled".

Due to T209089#4791149 and the additional failures I refactored the code, but the new code is not committed.

It does not make sense to keep this open. Closing as declined due to the community, I doubt it will change anytime soon.