Repository management

Jump to: navigation, search

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 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).


The repository handling is now centralized in the following four commands:

  • repocreate
  • repoupdate
  • repoexport
  • repocommit

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, there is a helper command repo which takes two arguments:

  • command: update, create (export and commit can be used too, but they don't make any sense!)
  • project name as above, or all

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/nike/REPOCONF or /resources/projects/REPOCONF. Remember to set REPO_RW to yes in REPOCONF. Then you can easily export the latest changes with repoexport, and commit them with repocommit (if you have permissions!).

MediaWiki extensions

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.

Version control URI


REPONG is the current system as of 2016. Example missing.


This section is here for legacy reasons. See New project setup for

# If not set, will not setup l10n-bot commit stuff for MediaWiki git extensions


# MediaWiki extensions, GIT

MediaWiki core

Regular exports checklist

Things to look for

  1. Translated namespaces (should be canonical), this is very common for messages like editpage
  2. metadata-fields (translated list items)
  3. Bad html
  4. Extra links, formatting and everything that does not seem to belong there, like usage of parser functions
  5. English strings
  6. 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.

  • run exportsp
  • 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

See mwcore-export.php

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.


  1. checked out version of MW1.13, 1.14, 1.15 branches with a valid LocalSettings.php (no running database required)
  2. updated $changed arrays with incompatible messages for core-1.1[345] 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).


  1. run nice php export.php --target=$HOME/export/114 --lang=* --group=core-1.14 to export all languages for core-1.14. Export folder is arbitrary.
  2. run a count of the current trunk messages using maintenance/language/countMessages.php. Make note of the count
  3. download the export results (except for English)
  4. fairly complete languages that were not yet part of a branch, can be added at your discretion. Also update RELEASE-NOTES and Names.php.
  5. remove MessagesXx.php that are not part of the branch.
  6. merge compatible changes to MessagesEn.php from trunk
  7. rebuild all messages files with php rebuildLanguage.php --lang=all --remove-unknown (or whatever is available for the branch)
  8. run a count of the current trunk messages using maintenance/language/countMessages.php. Calculate the number of added messages.
  9. 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.

See also