L10n:MozillaTranslator

MozillaTranslator is a tool to translate programs in the Mozilla family.

If you are looking for the newest version the MozillaTranslator tool, the latest 5.30 version is available from the following Kenai page: MT downloads page.

For developers, its source code is available through MT Kenai page. Since the release of MT v5.25, MozillaTranslator switched from Sourceforge.net to Kenai.com.

You can check MT bugs at Bugzilla@Kenai. Or look for open bugs in the product MozillaTranslator.

MozillaTranslator is written in Java. This means:

• that it will work on any platform that supports Java (Windows/Linux/Mac/Solaris etc.), and
• that you need to make sure you have Java 1.6 or above installed on your system.

How to Use

Current PDF manual

You can get the current, up to date manual as a PDF. Wherever the PDF manual and this wiki page differs, the PDF version should be taken as the normative one.

Overview of workflow

MT uses products as groups of localization files with a common root directory (for instance, you may have a product for Thunderbird, other for SeaMonkey, other for Dom, other for Toolkit, etc.).

You update your repository copy using your favorite repository tool, and then update the product(s) in MT This will remove obsolete strings and files from the internal database of MT, and will present you with a list of new and updated strings.

Hint: if you are starting a new localization, ALL strings will be marked as new or updated. MT puts a fuzzy flag (actually, it is more a kind of 'To Do' or 'Pending' flag) and saves it in its database. You can save your work in progress and reopen it later, selecting 'View Fuzzy' option in Edit menu, to continue working.

After translating those strings (if using the Edit Phrase dialog, you can get translation suggestions for strings having an original text equal to existing translations), you can run some automated tests to detect typical errors. After that, you export either the whole product or individual files.

Finally, you commit your changes outside of MT, using your favorite repository tools.

Recipes

Introduction

We aim to put here some recipes that may be useful at a certain moment for MT users, but that, due to its temporary nature, don't fit in the user manual.

Migrating contents when the directory structure changes

Overall, if you are a good MT user and you do things like:

• checking "Keep Original" flags for strings not needing translation, instead of just leaving the translation empty,
• struggling to get empty lists when running "Untranslated strings" and "View Fuzzy" if you are up to date in localization,
• regularly run QA checks and try to minimize them.

you will always do better if you can export a partial glossary and reimport it as needed. See the following example.

Let's assume you have a Firefox product in MT with the directory layout present in language packs, as you probably would need for a initial localization. The directory structure will look like this:

(ab-CD JAR root)
locale
|-- branding
|   |-- brand.dtd
|   `-- brand.properties
|-- browser
|   |-- aboutDialog.dtd
.
.
|-- browser-region
|   `-- region.properties
`-- ab-CD
    |-- alerts
    |   `-- notificationNames.properties
    |-- autoconfig
    |   `-- autoconfig.properties
    |-- cookie
    |   |-- cookieAcceptDialog.dtd
    |   `-- cookieAcceptDialog.properties
    |-- global
    |   |-- about.dtd
    |   |-- appPicker.dtd
    .
    .

but in the CVS and mozilla-central repositories the locale part looks like this:

toolkit
|-- locales
|   |-- en-US
|   |   |-- chrome
|   |   |   |-- alerts
|   |   |   |   `-- notificationNames.properties
|   |   |   |-- autoconfig
|   |   |   |   `-- autoconfig.properties
|   |   |   |-- cookie
|   |   |   |   |-- cookieAcceptDialog.dtd
|   |   |   |   `-- cookieAcceptDialog.properties
|   |   |   |-- global
|   |   |   |   |-- about.dtd
|   |   |   |   |-- appPicker.dtd
.
.
browser
|-- locales
|   |-- en-US
|   |   |-- README.txt
|   |   |-- chrome
|   |   |   |-- branding
|   |   |   |   |-- brand.dtd
|   |   |   |   `-- brand.properties
|   |   |   |-- browser
|   |   |   |   |-- aboutDialog.dtd

As you see, there is link point, usually at chrome (in CVS & mozilla-central), sometimes in a deeper point. For instance, toolkit/locales/en-US/chrome in mozilla-central matches locale/en-US and browser/locales/en-US/chrome matches locale/browser.

So, what you have to do is export partial glossaries in each link point of the old product and import them in the corresponding link point of the new point. Your Keep Original and Fuzzy flags will be honored for each string.

There will be some exceptions. Files hanging directly from the Platform neutral platform can't be part of a partial glossary (because they are not components), and Platform neutral itself can't be selected either, since it is not a component, but a platform. For these few files, you will have to export them individually and reimport them.

If you are a not so good MT user, however, you can just create a new product (or several ones; see next recipe to know why), run File -> Update on them (you'll get a list of all the strings in the ) and then run Edit -> Autotranslate. Most of the strings will be automatically filled, although if you do this you should review them, because for en-US strings with several possible translations, MT will choose one of them, which could not be the one you want.

From CVS to Mercurial in MT

So, you have a Firefox product in MT with a Platform neutral and, inside it, several directories (components in MT terminology) more or less like the second sample above, checked out from CVS. Now, you want to start working directly on mozilla-central (and l10n-central). What should you do?

The first thing to do, once you have your Mercurial local repository up and working, is create a new product... or more. With good oldie CVS, you could checkout just the locale content and, even more, you could checkout just the locale directories you were interested in. With Mercurial, partial checkouts are not possible, so you have your own Mozilla repository full copy (there are alternate solutions; read on).

A bit of history on MT

MT has been evolving from long ago, when L10n were done always on shipped en-US JARs and when Mozilla Suite had five L10n JARs: ab-CD.jar, ab-win.jar, ab-mac.jar, ab-unix.jar and CD.jar. MT thus referred to ab-CD.jar contents as Platform neutral platform, CD.jar as region platform (or regional files) and the other three as Windows platform, Mac platform and Unix platform. This JAR structure is now used just by SeaMonkey 1.1.x.

When Mozilla L10n switched to Source L10n, one of the many problems that MT had to solve were how to fit a directory structure in what had been designed for five JARs, and the patch consisted of providing a read from dir instead of JAR and put everything inside Platform neutral.

That has worked well (OK, more or less) :-) as long as you could instruct MT to use just one root L10n directory, but this is no longer the case with Mercurial.

MT could be changed for a MT product to have a list of root directories instead of just one, and maybe someday it will do, but it will probably won't happen before SeaMonkey 1.1.x dies (and SeaMonkey 2.0 finally conquer the web, if I may add). ;-)

Enough chatting, what's next?

Anyway, we need to workaround the full-fledged repository problem. These are your options:

• create one product for each root directories. This means browser, extensions/reporter, dom, netwerk, security and toolkit. Besides that, you will need to create one tiny product for other-licenses/branding/firefox. For each one of the above, the root directory will be .../locales/en-US.
• FrenchMozilla has just announced they are providing an en-US only Mercurial repository comprising both mozilla-central and comm-central. If you are happy with a non-official solution (it's not like if they were third-party, they are your french equals!) ;-) you have a pretty easy and comfortable solution.
• if you are using a filesystem with symbolic links support (i.e., Linux or Mac), you can create symbolic links in a separate directory so it contains just the locale part. Thanks to Alexandru Szasz, from Narro, for this inspiration. See this example for browser.

For the last two options, you should be able to adjust your current MT product paths so you can keep using it just like with CVS. Keep in mind that MT doesn't really know if you are using CVS, SVN or Mercurial. It is just instructed to read directory subtrees and ignore "CVS" and ".svn" directories it finds.

If you have opted for the first solution, you will find yourself with some new products completely untranslated (once you Update each of them). To migrate the existing translation in the old product, you need to export partial glossaries from the old product, selecting the link origin (see the previous section) and importing them into the link target.

Defining symbolic links for browser

This is an example just for browser, without shared components, but it should suffice to get the idea.

; Assuming we are in a directory containing mozilla-central/
$ mkdir locale-only
$ cd locale-only
$ mkdir -p browser extensions/reporter other-licenses/branding/firefox/
$ cd browser; ln -s ../../mozilla-central/browser/locales/; cd ..
$ cd extensions/reporter; ln -s ../../../mozilla-central/extensions/reporter/locales/; cd ../..
$ cd other-licenses/branding/firefox/; ln -s ../../../../mozilla-central/other-licenses/branding/firefox/locales/; cd ../../..