Repository management

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

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

Each command takes two arguments:
 * project name:
 * 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. 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  which takes two arguments:
 * command:  (  and   can be used too, but they don't make any sense!)
 * project name as above, or

This command automatically works in the  location and uses   user. So for example you can update everything with just  or just one project with. 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  file and issuing   for example. For examples see  or. Remember to set  to   in. Then you can easily export the latest changes with, and commit them with   (if you have permissions!).

Mediawiki extensions
To be able to commit as  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

 * 1) Requirements and process: Translating:New project, File format support.
 * 2) Best practices we usually enforce (main pain point): Translating:Localisation for developers.
 * 3) Adding a project when you think it's "good enough":
 * 4) * create a project page with all the information;
 * 5) * submit a patch to the translatewiki.git repo similar to (checker and suggester are optional; they make your translators more productive), see reference documentation and tutorial.

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. Extension special page aliases can be exported and updated automatically. Because of this, it is most efficient to just export everything regularly.
 * run
 * 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.

Prerequisites

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

Steps

 * 1) run   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   (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.