What every Mozilla translator should know

l10n stands for localization = l + another 10 letters + n

Mailing lists and other resources

There are several mailing lists to keep the track of what's going on, which are available as newsgroups, as well, both on news.mozilla.org and Google groups:

The main l10n list 

Also available as mozilla.dev.l10n, .l10n in short. Discussion about localization take part here just as well as l10n-focused announcements.

Planning list 

Also available as mozilla.dev.planning, .planning in short. The Mozilla project discusses general planning and schedule questions here. Discussions of interest to the general Mozilla developer community are at least notified here.

Translate the Mozilla web 

or mozilla.dev.l10n.web, we moved announcements and discussions about the translation of the Mozilla web pages to this group.

All these groups are pretty low traffic.

To keep the track of what's going on, it's also a good idea to read the Planet Mozilla L10N

When you have a problem

• Use the above mailing lists
• The person in charge of the Mozilla l10n is Axel Hecht (l10n at mozilla.com), Pike on IRC
• Another interesting way of getting help is the IRC channel #l10n at irc.mozilla.org

Useful Tools

• The L10n Dashboard
• Pontoon
• Narro
• Translate Toolkit
• Koala 0.1
• MozillaTranslator

Mercurial

The hg is organized into several repositories, sometimes called branches. We have the main repository called mozilla-central (or trunk) where the day to day developing work is done. When a development is started for an specific version, a new repository is created under hg.mozilla.org/releases/. All the content of the trunk is copied to this new branch so that the developing work is done in two (or more) parallel places: the generic trunk and the version oriented branch(es). For every branch and every locale, there is a separate repository for localization files committed by the localizers.

Some branch/release names identified:

And, on the former revision control system, CVS:

• CVS trunk (the default branch) -> Firefox/Thunderbird 3.0.x Branch
• MOZILLA_1_8_BRANCH -> Firefox/Thunderbird 2.0 Branch

Mozilla Cross-Reference

Mozilla Cross-Reference is a web site mirroring the content of the Hg server. Here we can easily have a look into other languages translations.

Bugzilla, the bug-tracking system

You do need an account in Bugzilla

You should configure the account to Watch the following addresses:

• [email protected]
• [email protected] (specific for calendar related bugs)

This way you will receive mail for bugs affecting many or even all locales.

When you create a bug, if you want the person in charge of the l10n to follow up your bug you should CC: [email protected]

If you choose to make changes to your localization, you should make the changes local to your disk, push them to your Hg repository on Merucial, test the changes on a nightly/tinderbox build, fix any errors if some are found and test again, and send the new changeset ID as your "opt-in" revisions to the l10-drivers.

There is one exception to this process.  If you choose to make any changes to the productization elements (i.e. search plugins, protocol handlers, RSS/live bookmarks), you will need to upload a patch with the suggested changes to Bugzilla and get approval before pushing those changes to your Hg repository.

• Do the changes in your local disk
• Create a diff file with the changes

$ hg diff -p -U 8 FILENAME

• Create a new bug:

Product: 	Mozilla Localization
Component:	your language
...
CC:		[email protected]
Assigned to: you
explain what you need!
Specify the branch (1.9.2 for Firefox 3.6, 1.9.2.1 for Firefox 3.6.1, ...)

• attach the diff file to the bug:

Content Type: patch
Mark the approval1.9.xxx with ? asking for approval (use the appropriate branch)

• If you get the approval you will see who_is_ap:approval1.8.xxx+ Now, you can upload the changes approved to the CVS server. When you commit the changes you must write in the comment the Bug number, what you have changed and who has approved. For example:

bug 12345, fix typos and resize prefwindow, a=l10n

• As soon as you have committed, put the bug in FIXED state and write fixed1.8.xxx in the keyword field
• You have to verify in the next build that the changes have been successful. If so, change the state of the bug to VERIFIED and write verified1.8.xxx in the keyword field

Tinderbox

In Tinderbox you can see the result of the build process. Once you have made some changes in Mercurial, as soon as the next build is done you can check the Tinderbox and see if something was wrong.

• l10n Tinderbox

When the color is green, it means that the build process has finished with no errors. In this case the resultant installable file will be available in the Mozilla FTP servers:

• Firefox Nightly Builds
• Thunderbird Nightly Builds

QA (Quality Assurance)

In order to assure the quality of a build we should make some tests using https://litmus.mozilla.org/