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 hg.mozilla.org. Depending on which branch you work on, the URL of your repository might look like this:

http://hg.mozilla.org/releases/l10n-central/x-testing

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.

Configuration

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

Add the following lines to your ~/.ssh/config file, replacing user@host.domain with your Mozilla LDAP account name:

Host hg.mozilla.org 
User user@host.domain

If you have already cloned the remote repository using the HTTP protocol using this command: $ hg clone http://hg.mozilla.org/releases/l10n-central/x-testing 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):

[paths]
default = hg.mozilla.org/releases/l10n-central/x-testing
default-push = ssh://hg.mozilla.org/releases/l10n-central/x-testing

If you haven't already cloned the remote repository, enter this command: hg clone ssh://hg.mozilla.org/releases/l10n-central/x-testing

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://hg.mozilla.org/releases/l10n-central/x-testing).

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:

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 <email@example.com>
date:        Mon Nov 23 18:08:25 2009 +0100
summary:     Added search bar strings

Now run the hg outgoing command to compare the local repository on your machine with the remote repository on hg.mozilla.org.

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://hg.mozilla.org/releases/l10n-central/x-testing
searching for changes
changeset:   0:7c543e8f3a6a
tag:         tip
user:        Your Name <email@example.com>
date:        Mon Nov 23 18:08:25 2009 +0100
summary:     Added search bar strings

Make sure this output is accurate before continuing.
Once you've made sure the outgoing output is accurate, push this changeset to hg.mozilla.org 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://hg.mozilla.org/releases/l10n-central/x-testing
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 hg.mozilla.org! You can now visit http://hg.mozilla.org/releases/l10n-central/x-testing 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 hg.mozilla.org host. This should be your Mozilla LDAP account name. Next, try issuing the following command: $ ssh hg.mozilla.org

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

No interactive shells allowed here!
Connection to hg.mozilla.org closed.

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

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 http://pastebin.mozilla.org and ask in #l10n on the irc.mozilla.org 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.

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:

File a bug requesting the review.
Attach your files to the bug. Once attached, open the attachment details.
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.
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.

« Previous