When MediaWiki switched to GIT in 2012-03... Finland melted. Nike took the opportunity to change the organic scripts for our repo management into something more standardized. The scripts are also now on Wikimedia's git repositories.
Currently the translatewiki.net group configuration files are at
/home/betawiki/config, but they come from the git repository mentioned above..
See also Amir's summary for MediaWiki (which is actually longer than this page and has some things not covered here).
- 1 Commands
- 2 Special command: repo
- 3 Mediawiki extensions
- 4 Adding a new project
- 5 Example REPOCONF
- 6 MediaWiki core
- 7 See also
The repository handling is now centralized in the following four commands:
Each command takes two arguments:
- project name:
freecol, mediawiki, mediawiki-extensions, mifos, mwlib, WikipediaMobile
- optionally a directory to use as working directory (defaults to current directory)
Each of the commands will crawl up the directory tree until it finds a file named
REPOCONF. All project directories will be placed under that directory.
Special command: repo
To ease up the management of the read-only repositories used by translatewiki.net, there is a helper command
repo which takes two arguments:
commitcan be used too, but they don't make any sense!)
- project name as above, or
This command automatically works in the
/resources/projects/ location and uses
betawiki user. So for example you can update everything with just
repo update all or just one project with
repo update freecol. Remember that you still need to sync the changes into the wiki one way or another.
You can easily create a new checkout or clone of any of the support projects (pending migration) by creating a
REPOCONF file and issuing
repocreate freecol for example. For examples see
/resources/projects/REPOCONF. Remember to set
REPOCONF. Then you can easily export the latest changes with
repoexport, and commit them with
repocommit (if you have permissions!).
To be able to commit as
l10n-bot for the MediaWiki git extension updates, you need to know the pass phrase for the private key. Ask Niklas or Siebrand.
Adding a new project
This part was split to New project setup, see there.
# If not set, will not setup l10n-bot commit stuff for MediaWiki git extensions REPO_RW=yes REPO_FREECOL=https://freecol.svn.sourceforge.net/svnroot/freecol/freecol/trunk/data/strings REPO_MIFOSemail@example.com:mifos/head.git # Mediawiki extensions, SVN #REPO_MWEXTSVN=http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions # Read-only REPO_MWEXTSVN=svn+ssh://firstname.lastname@example.org/svnroot/mediawiki/trunk/extensions # Mediawiki extensions, GIT #REPO_MWEXTGIT=https://gerrit.wikimedia.org/r/p/mediawiki/extensions # Read-only REPO_MWEXTGIT=ssh://email@example.com:29418/mediawiki/extensions REPO_MWLIBfirstname.lastname@example.org:pediapress/mwlib.git REPO_MWLIBRLemail@example.com:pediapress/mwlib.rl.git REPO_WIKIPEDIAMOBILEfirstname.lastname@example.org:wikimedia/WikipediaMobile.git
Regular exports checklist
Things to look for
- Translated namespaces (should be canonical), this is very common for messages like editpage
- metadata-fields (translated list items)
- Bad html
- Extra links, formatting and everything that does not seem to belong there, like usage of parser functions
- English strings
- linkprefix .. easily broken
Extension special page aliases
Exporting special page aliases for extensions is part of
bpmw. Extension special page aliases can be exported and updated automatically. Because of this, it is most efficient to just export everything regularly.
- review the outcome and make fixes where needed (see advice on top of the page)
- commit. See mwr:42268 for example commit message. Alternatively commit with a regular extension localisation export run.
Magic words, special pages aliases, namespaces
Backporting to stable
This section describes the process of backporting translations to earlier branches. Only update branches that are not end of life. Backports to stable should happen about once every two months, or just before a release. Usually the release manager will somehow show activity. Try to coordinate with the release manager so that you have time to perform these steps.
Updating 3 branches takes about 2 hours. Actual times can vary based on your level of experience.
- checked out version of MW1.13, 1.14, 1.15 branches with a valid LocalSettings.php (no running database required)
- updated $changed arrays with incompatible messages for core-1.1 in /var/www/w/TranslateSettings.php. This step is extremely important. All messages with a changed meaning or changed parameters should be considered incompatible. Note the most recent version that was checked when updating the arrays in /var/www/w/TranslateSettings.php (outdated version).
nice php export.php --target=$HOME/export/114 --lang=* --group=core-1.14to export all languages for core-1.14. Export folder is arbitrary.
- run a count of the current trunk messages using maintenance/language/countMessages.php. Make note of the count
- download the export results (except for English)
- fairly complete languages that were not yet part of a branch, can be added at your discretion. Also update RELEASE-NOTES and Names.php.
- remove MessagesXx.php that are not part of the branch.
- merge compatible changes to MessagesEn.php from trunk
- rebuild all messages files with
php rebuildLanguage.php --lang=all --remove-unknown(or whatever is available for the branch)
- run a count of the current trunk messages using maintenance/language/countMessages.php. Calculate the number of added messages.
- commit. See mwr:47278 for example commit message. This can cause huge commit mails (5MB+ is not unusual).
Backporting translations for other message groups is not (yet) available.