You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.



 

How to localize Mozilla

newsgroup discussion / mailing list
Mozilla Localization Project Staff

MLP [Localization Project home] | [Localization docs] | [How To Contribute]

Introduction

Here are the basic, but necessary, steps required to create a localized version of Mozilla in your own language, and make it available to the mozilla.org community:

  1. Register as MLP contributor(s)
  2. Download a build
  3. Work on the files
  4. Use Localization/Leveraging tool and glossary files
  5. Package everything back
  6. QA your work
  7. Submit the localization to mozilla.org

Get the program

You can download a release build for your system at

Mozilla Application Suite
Mozilla Firefox browser
Mozilla Camino Mac browser
Mozilla Thunderbird mail client
Mozilla Sunbird calendar
These are the working executables to which the Mozilla Localization Project bases its localization releases.

If you wish to quickly synchronize to Mozilla releases, as the work on them progresses, you can download a recent nightly build

    ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/
and start localizing the closest possible thing available, to what the upcoming release is supposed to be. This will reduce the work needed once the actual release has been completed. |Beware| that, these ones are experimental builds. They could work, or sometimes not, or even damage the data in your PC. You're warned.

What needs to be localized

 
The localizable resources in Mozilla based products are supposed to be all externalized into editable files, which can be categorized into some groups:
  • chrome files: They're an actual part of the application user interface. These files needs to be registered in order the application be able to locate and access them.
    Once the resources are registered can be reached through a "fake" address path (an URI), in a similar way a web page contained in the hard drive of a web server can be accessed through an URL address.
    Once chrome resources are registered for several languages, it's easy for the application to bind the "fake" address to the actual location of one of these language resources, so that the UI language can be transparently switched.

    In the English mozilla.org distribution of Mozilla, these files are packed inside zip archives placed in the binaries chrome/ folder:
    • "en-US.jar": contains the bulk of the UI language resources, used by the builds of every platform.
    • "en-win.jar" ("en-unix.jar", "en-mac.jar"): contain all the platform-specific UI resources.
    • "US.jar": contains all the exteranl references (URL/URI) used thoughout the user interface. This allows regional specific contents linking.

  • profile defaults (optional): They're the localized user profile template files used at the time a new profile is created, and live into defaults/profile/[country-code]/ binaries folder.

  • additional material (optional): In this category can fall all the other files not strictly needed by the application for the conventional operations, like: and so on..

Use Localization/Leveraging tools

Use localization/leveraging tools to improve productivity. It'd be a waste of time and error prone if we'd need to localize each build from scratch. With tools like Mozilla Translator, you can identify the strings are new or changed, focus your work just where it's needed.

Also, programs like Mozilla Translator can free the localizer from the burden of directly handling files, extracting the original localizable resources from its archives, and once localized, package back the material in a distributable form.

Translation Glossary & References

Here are quite a few translation glossaries and other reference material contributed by the open source community. They are good sources of references during translation.

Packaging and installing

There are basically two ways to make your work available for the public:

  1. As an installable language pack (*.xpi). One small compressed archive containig just the localized resources and an installer script. An user with Mozilla installed, can have your language available just with one click.
  2. A localized full build, also containing all the binaries for a particular platform/OS.
See details here.

XPI
Of course having an installable XPI package is the first option, since every Mozilla user can conveniently add his favourite language available even on a multi user environment or on an already installed copy of the program, or on a non localized version found on a magazine CD.
Installing is as easy as open the file in the browser, or follow its link on the web. Once the installation has completed (sometimes after an application restart, with Quick Launch disabled) the language can be chosen in the preferences under the Language/Contents category. (Edit | Preferences | Appearance | Language/Contents)

Full localized build
If you need to create a complete distribution of Mozilla in your own language, this is the way.
Although Mozilla is a fully open source application, I'd like to discourage you &mdash when this is a viable choice — from redistributing binaries other than the ones compiled by mozilla.org. The reason is the main mozilla.org's aim for releasing this software in the public, is collecting feedback on its functionalities (or their lack thereof); having the very same binaries distributed ease this process and possibly focuses the developers just on the bugs they're responsible of ;)

The main kinds of distributable builds can be categorized in:

  • Plain archieves of the binaries (like tar.gz, zip)
  • Full installer builds. They can either contain an installer archived inside a conventional compressed file holding the remaing part of the application, or one big executable with all the binaries merged in its body (like the typical MS Windows installer files).
  • Net installer builds. This is a compiled build, modularized in several XPI archives, plus a small standalone installer. The installer, once downloaded and executed, is able to collect the user preferences and start the download of just the selected components.
  • Unix package maintenance system bundles (like *.rpm, *.deb, ..). These usually constitute script based self installer packages, managed by the system they're built for.

QA the localization results

Of course your work needs revision. Quality Assurance is vital to have a large project like Mozilla coherent, usable and bug free.

There are several levels of testing, which can iteratively improve the overall quality of the localization:

  • Once your language is active in Mozilla, you can explore the large amount of dialog windows constituting the Mozilla interface, by loading the XUL user interface files in the browser.
    Within the chrome/ folder look inside the .jar archives (with a PKZip compatible utility) and look for *.xul files. They're contained under a content/ folder, grouped by components.

    With Navigator open these files typing the corresponding "chrome://" URL in the address bar.

    Example: let's open the file abSelectAddressesDialog.xul, found inside messenger.jar, under the path /content/messenger/addressbook/. We need to type in the Navigator address field: chrome://messenger/content/addressbook/abSelectAddressesDialog.xul

    Often the strings you're about to localize in a DTD file, are used in by a .xul file with a similar name (E.g. abSelectAddressesDialog.xul uses the strings placed in abSelectAddressesDialog.dtd).

  • Use the program! Yes, this is of course the best practice. Beside the day by day usage, try to plan a systematic coverage of all the available features, menu item by menu item, button by button.

  • Encourage feedback from users, since it is usually easier for a third person see mistakes made by someone else.

Submitting

 

Once you're done, please take contacts with MLP Staff, so we'll make your work publicly available from the Mozilla ftp site for download.

But don't just stop there. Let the world knows about your work! Take contact with some news site in your language and let the people know a program talking their language exist. This might even more important when your work is not published in synch with English mozilla.org releases.

You might find sometimes a CC list for your announcement messages could be enough. Some other times you might want to create an account in some sites where you can post an announcement message through an online form.

This is likely to have the effect of more people downloading and testing your work. If they find something skipped under your eyes, be open and accept their feedback. As I said, quality can be improved mostly using the application.