Your Search Results

    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 and Google groups:

    The main l10n list 
    Also available as, .l10n in short. Discussion about localization take part here just as well as l10n-focused announcements.
    Planning list 
    Also available as, .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, 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, Pike on IRC
    • Another interesting way of getting help is the IRC channel #l10n at

    Useful Tools


    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 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:

    <caption>Branches in hg</caption>
    Mozilla source + en-US Localization files for [ab-CD] locale Corresponding Firefox version
    mozilla-central l10n-central (trunk)
    mozilla-1.9.2 l10n-mozilla-1.9.2 Firefox 3.6
    mozilla-1.9.1 l10n-mozilla-1.9.1 Firefox 3.5

    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:

    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:

    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
    Product: 	Mozilla Localization
    Component:	your language
    Assigned to: you
    explain what you need!
    Specify the branch (1.9.2 for Firefox 3.6, for Firefox 3.6.1, ...)
    • attach the diff file to the bug:
    Content Type: patch
    Mark the with ? asking for approval (use the appropriate branch)
    • If you get the approval you will see 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 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 in the keyword field


    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.

    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:

    QA (Quality Assurance)

    In order to assure the quality of a build we should make some tests using

    Document Tags and Contributors

    Contributors to this page: stasm, AxelHecht, Igartua,, RickieesES, Diablownik
    Last updated by: RickieesES,