Skip to main content

Visit Mozilla.org

Create a new localization

From MDC

DRAFT
This page is not complete.

This page outlines the process for getting new localizations from the stage of mere interest to an official release of Firefox or Thunderbird. (If you want to start a SeaMonkey localization, note that SeaMonkey 1.x has a different process, see the SeaMonkey L10n page, SeaMonkey 2 and later follow the process described here.) Other Toolkit-based Mozilla projects may be similar to this. If you're interested in translating the Add-ons web site, please read wikimo:Update:Localizers.

Please note that if you have localized other software before, the way we approach localizing Firefox and Thunderbird may be a bit different due to the unique success of Firefox. Check out Axel's blog post for more details on our thinking here.

Contents

[edit] Joining an existing team

Localizing Mozilla applications is a lot of work - but that means there's plenty of opportunity to get involved. Some people may already be working on your language of interest; if so, they will be happy to have some help. You can find others who are already working on the same language by looking at the list of localization teams and the open team registration bugs. A Google search might also find existing work.

[edit] Starting a new team

If there isn't any information on an ongoing effort in your language, you should begin by creating a team page on wiki.mozilla.org, similar to that of the German team. Give it the same name as theirs, except replacing the language code de with your own. Firefox, Thunderbird, and XULRunner share the localization of a core piece called "toolkit", so if you start localizing one of those applications when some other team is already working on another one, you'll need to coordinate with them about that.

There are some resources available for people starting new teams. We have a server dedicated to l10n that you can get access to, or you can create a project on mozdev.org or SourceForge which will provide you with mailing lists, a place to store your code and so on. These services provide a more complete package, which the l10n server doesn't try to reproduce.

[edit] Bootstrapping a localization for review

Currently, new localizations should target Firefox 2.0.0.x. (This is subject to change as Firefox 3 approaches.) To get the localizable files for Firefox 2, you start by checking out the en-US (US English) files from CVS by using the following: 

cvs -d:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -r MOZILLA_1_8_BRANCH mozilla/client.mk mozilla/tools/l10n/l10n.mk
cd mozilla
MOZ_CO_PROJECT=browser make -f client.mk l10n-checkout

Substitute browser for mail in the last line for Thunderbird. This will create a mozilla directory with a series of mozilla/<modulename>/locales/en-US directories, one per localizable module <modulename>. The most important modules are browser (Firefox), mail (Thunderbird), and toolkit; getting either of those first two gets you toolkit as well. The master makefile client.mk has LOCALES_<modulename> variables, which hold the list of localizable modules, and that's why we're using it.

Create a .mozconfig file with the following contents, in the same directory as client.mk, substituting ab-CD with your locale code: 

. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../ab-CD
mk_add_options MOZ_CO_LOCALES=ab-CD

The copy of the files which you localize will be in a slightly different directory structure. For each module <modulename> you will have a l10n/ab-CD/<modulename>/ directory, and files in the two directories have the same subpaths. That is, using Firefox (browser) in German (de) as an example, the file mozilla/browser/locales/en-US/chrome/browser/browser.dtd will have a counterpart at l10n/de/chrome/browser/browser.dtd. Exploring the l10n directory, you will see mostly DTD and properties files, both of which can be edited with plain editors, as long as you make sure they're saved in UTF-8. There are a few community-supported tools, too.

The simplest tool is the makefile l10n.mk that we already mentioned above. It offers two targets, check-l10n and create-%.

To check the completeness of your localization, you can run 

make -f tools/l10n/l10n.mk check-l10n

as long as you have a .mozconfig as described above. It will spew out a bunch of warnings, but it will also show you missing files and entities in your localization (compared to en-US) as well as obsolete ones.

The second target can optionally help you to bootstrap your localization. You can create all the files necessary using the following command, again replacing ab-CD with your language code: 

MOZ_CO_PROJECT=browser make -f tools/l10n/l10n.mk create-ab-CD

The downside of this is that the check-l10n target in l10n.mk (mentioned just above) won't give you details on how far you are in translating, as create-ab-CD just copies the files over, so it looks like it's 100% done. That is, you'll have all the strings, but untranslated, so you'll need to do the progress checking yourself.

Once you start working in CVS (see below), it will be good to keep an eye on both the 1.8 branch (MOZILLA_1_8_BRANCH) and the trunk (HEAD) to see what is changing. You can use L10n's Bonsai for that (Bonsai is a powerful code browser).

To keep up with the changes in the Mozilla codebase, run the l10n-checkout target regularly, and check the notifications about updates to see which files have changed. You will want to verify that your locale will build OK by running: 

make -f tools/l10n/l10n.mk check-l10n

(again, assuming that you have your .mozconfig set up right).

Note: There are some things that shouldn't be localized:

  • Legal documents - those shouldn't live in the l10n repository, but some do; these are supposed to be translated by hired professionals with contribution and review from the localization team.
  • Command keys - there are the entities and properties that end in .key and .commandKey. These are supposed to be the same throughout all localizations.
  • Interface sizes - there are entries like 36em or width: 45em; height: 32em. These define the size of dialogs and are there for you to adjust the dialogs if needed by your localization. Translating them will only make them stop working.
  • Strings like true or false and the like are probably keywords; check whether they're intended to be localized by translating them, or by setting the value, and seeing what breaks.

[edit] File registration bug

Going forward, once your localization is completed, the next step is to get an official Firefox or Thunderbird release in your language. To get an official localization, you need to register with Mozilla. This way we know who to contact if we need to. File a registration bug using this bug link, which sets the right component. If multiple teams try to submit a localization, this will be resolved within a single registration bug, so before filing a new registration bug, make sure that there isn't one already. We strongly prefer that everyone cooperates to make a better and stronger team.

[edit] File CVS account bug

The owner also needs to file a bug requesting a CVS account. Official localizations are stored in CVS. To get CVS write access to the l10n repository, you need to follow the instructions regarding the CVS contributor form, and submit your localization for review. Write access to the CVS repository requires a voucher, which, for the owner, will be done based on the review by Mozilla. For peers of a localization, the owner can vouch (once she or he is registered).

[edit] Submitting a localization for review

Please attach a zip of your localization (mentioning the platform you're working on) to the registration bug, and request review on the patch from l10n@mozilla.com (set the review flag to ?).

Note that if your zip file is over 300 KB you will need to split it into multiple archives as Bugzilla will complain. You shouldn't have that problem if you're using the .tar.gz (gzipped tar) format. ZIPs come out a lot bigger, because the algorithm really doesn't like lots of small files. 7-zip will create .tar.gz files on Windows.

[edit] Fix remaining bugs

In the review process, there will usually be comments to be addressed, which should be fixed before the initial commit.

If you have problems, there should be someone on the #l10n IRC channel able to help.

[edit] Following your localization

Mozilla's code is always changing. Some useful tools to keep track of the state of your translation are:

[edit] Localize web-based parts

For the bookmarks and start pages, some additional localization work needs to be done. See the Firefox Extras page for now.

[edit] Trademarks review

To be compliant with the Mozilla Foundation Trademarks Policy, there needs to be review of the parts of your localization which are relevant to trademarks.

You should:

  • Ask approval for any changes in bookmarks and/or plugins for your locale. For an example of such a request, check bugs like: 347295 346549
  • Do not change the names in the files brand.dtd and brand.properties.
  • Read carefully the Website Policy for Localization Teams document, which explains how you can use Mozilla trademarks in your team sites.
Retrieved from "http://developer.mozilla.org/en/docs/Create_a_new_localization"