Release phase

You've made it! You've setup up your local and remote environments, you've selected your L10n tools and projects, done some localization and even some testing! Now you're ready for the final phase: becoming an official L10n release. Here, we'll continue to stay true to the original intent of this guide and only present you with the technical information you need to become an official release. We'll primarily focus on getting your release repository setup and the Mercurial commands you'll need to know to use that repository.

For more information on the release part of the L10n process, visit the Mozilla wiki here.

Your official release repository

Now that your locale has been registered, the localization files will live on Mozilla Mercurial server at Depending on which branch you work on, the URL of your repository might look like this:

If you followed the Koala or plain text approach, you probably already have a local clone of the repository. Otherwise, in order to be able to make any changes to the localization files, you will need to clone the repository on your local machine and work in the local clone.

There are two different protocols you can use to connet with your Mercurial repository: HTTP and SSH. Be advised that there's an important distinction between them. You can pull using both, but you can only push through SSH. Consequently, if you already have a local clone that you pulled using HTTP, you'll need to modify a config file to tell Mercurial to push through SSH. Let's go over configuring your connection protocols.


Before you try pushing, you need to tell SSH which username you wish to use for connecting with This should be your Mozilla LDAP account name.

  1. Add the following lines to your ~/.ssh/config file, replacing user@host.domain with your Mozilla LDAP account name:
User user@host.domain
  1. If you have already cloned the remote repository using the HTTP protocol using this command: $ hg clone then you will need to edit the .hg/hgrc file (inside the x-testing local clone) to tell Mercurial to push using SSH. Your .hg/hgrc file shoud look like this (add the emphasized line):
default =
default-push = ssh://
  1. If you haven't already cloned the remote repository, enter this command: hg clone ssh://

Mercurial will let you know that it's cloning the repository:

destination directory: x-testing
requesting all changes
adding changesets
adding manifests
adding file changes
added 4 changesets with 242 changes to 239 files
updating to branch default
239 files updated, 0 files merged, 0 files removed, 0 files unresolved

The default push URL is the same as the default pull URL (i.e., ssh://

You should now be able to push to the remote repository!

Commit, outgoing, and push

You should try to commit your work regularly as you progress through the localization files. Keep in mind that the hg commit command will save your changes locally (in the local clone). With the hg push command you can send the changesets to the remote server. Here's how that's done:

  1. Run this command to see recent commits in your local clone: $ hg log -l 3

You should a list of the most recent commits, similar to this one:

changeset:   0:7c543e8f3a6a
tag:         tip
user:        Your Name <>
date:        Mon Nov 23 18:08:25 2009 +0100
summary:     Added search bar strings
  1. Now run the hg outgoing command to compare the local repository on your machine with the remote repository on

The hg outgoing command compares the two repositories and lists all changesets that are present locally, but not in the remote repository. These changesets will need to be pushed to the remote repository. The output will look something like this:

comparing with ssh://
searching for changes

changeset:   0:7c543e8f3a6a
tag:         tip
user:        Your Name <>
date:        Mon Nov 23 18:08:25 2009 +0100
summary:     Added search bar strings
  1. Make sure this output is accurate before continuing.
  2. Once you've made sure the outgoing output is accurate, push this changeset to by running the hg push command.

Mercurial will connect to the remote repository, authenticate through SSH and send the changesets. The output should look something like this:

pushing to ssh://
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 2 changes to 2 files

Congratulations! Your changeset has been successfully pushed to! You can now visit in your browser to see the new changeset in the remote repository.

Troubleshooting SSH

If pushing fails, make sure your ~/.ssh/config has the correct User set under the host. This should be your Mozilla LDAP account name. Next, try issuing the following command: $ ssh

If SSH is working fine, you should see the following message:

No interactive shells allowed here!
Connection to closed.

If you don't see this message, try running the same command in a more verbose mode (with the debugging information): $ ssh -vvv

This should tell you why your connection is not succeeding. If you can't figure it out on your own, copy the output of the above command, paste it on and ask in #l10n on the server.

Technical and sign-off reviews

You've done some localization work and your ready for it to be released. The merge date for migrating from one product release channel to the next is rapidly approaching. You need to make sure that your work can effectively be compiled into a build for the next release channel. Do you know whether to ask for technical review of your work or a sign-off review? Do you know what what exactly is reviewed in each process? Technical and sign-off reviews apply to different localizations in different ways. Here's the basic difference between the two.

Technical review Sign-off review
  • Performed as a QA measure on a revision pushed to a new locale's L10n aurora repo in Mercurial.
  • Very comprehensive. Covers the entire product.
  • Focus is on technical accuracy and completion of L10n work; not translation quality.
  • Only performed on the first revision a new locale wants to have released to the public.
  • Must be approved prior to migrating your revision from one release channel to the next (e.g., Aurora to Beta).
  • Performed as a QA measure for maintaining a localization from release-to-release.
  • Only new L10n work is evaluated. This is done by generating a diff between the new release revision being considered and the previously approved release revision.
  • Focus is still on technical accuracy and completion of L10n work; not translation quality.
  • Release revisions are evaluated, not entire L10n repos.
  • Sign-offs do not need to be approved before revision merge between release channels, although it is recommended.

There is a specific process to follow in Bugzilla for requesting these reviews:technical review.png

  1. File a bug requesting the review.
  2. Attach your files to the bug. Once attached, open the attachment details.
  3. In the attachment details, select the ? from the dropdown menu next to the review flag or the appropriate approval flags (see image). This will display a text box to assign the review to someone.
  4. Enter :Pike as the Requestee.

We will perform a technical review of your work and provide you with feedback. We're happy to work with you to make sure that your work is fully functional.

For more detailed information about reviews for new localizations and sign-offs for maintenance releases, visit the technical review and sign-off review pages.

Tah dah!

Once again, congratulations! You've arrived at the end! Feel free to come back to refer to this tutorial as often as needed. We're happy to have you as a new contributor to Mozilla L10n and look forward to working closely with you.

Document Tags and Contributors

 Contributors to this page: Sheppy, teoli, jbeatty, DavidWalsh
 Last updated by: Sheppy,