Branches

Mozilla's Mercurial version control is organized into several repositories, also called branches. We have the main repository called mozilla-central (or trunk) where the day to day development is done. Every 6 weeks, this work is merged onto mozilla-aurora. Aside from these merges, mozilla-aurora is string frozen, and thus the best place for localizers to start working. Once the code stabilizes, it's merged to mozilla-beta, from which we then go to release.

For very active localization teams, following central is great and rewarding, but most localization work is expected to happen on aurora. There shouldn't be need to change during the beta phase.

Tree rules

There are different set of rules for landing translation for your locale, depending on which branch you want to land on. One rule is common, though--all changes to productization require review.

Productization

All landings on all branches that change search, rss readers or protocol handlers need a bug, and a patch reviewed by Stas prior to landing. That basically affects anything inside browser/searchplugins and browser/chrome/browser-region. This rule supersedes the ones following below. Other apps might impose additional rules.

Regular changes

Trunk

This is for mozilla-central and l10n-central. If you wish, you can follow the development progress in mozilla-central and keep your translation up-to-date with the bleeding edge version of Firefox trunk. In this case, you're free to land translations in l10n-central/[ab-CD] without any additional reviews. (Except for productization changes.)

Active

For localization, active branches are the current stable or nearing stability ones. You're free to land changes to translations without review, however, after the landing, if you want to include the change in an upcoming milestone (minor update, beta or RC release), you need to:

1. test it in a nightly or a tinderbox build, and
2. ask the l10n-drivers to use the updated translation by giving them the new changeset's revision number. This will become a so-called opt-in revision, which l10n-drivers will review and approve.

Legacy (3.0.x)

Since 3.0.x was released from the code in CVS, different rules apply for check-ins here. You're free to commit your changes if all of the following conditions have been satisfied before the landing:

• the change has a bug on bugzilla with an English description, and
• the bug has a patch submitted to bugzilla, where the owner or peer responsible for the patch requests a review from l10n@mozilla.com, and
• the patch has been positively reviewed (review+) by one of the l10n-drivers, and
• one of the l10n-drivers has asked for an approval1.9.0.x for the patch, and
• the approval1.9.0.x has been granted by Axel or another release-driver.

In-product Web Parts

Changes to in-product web pages are managed by Pascal.