How to localize Mozilla |
|
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:
- Register as MLP contributor(s)
- Download a build
- Work on the files
- Use Localization/Leveraging tool and glossary files
- Package everything back
- QA your work
- 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
If you wish to quickly synchronize to Mozilla releases, as the work on them progresses, you can download a recent nightly build
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 |
- 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:
- Mycroft search plugins for local search engines,
- spell checker dictionaries,
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:
- 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.
- A localized full build, also containing all the binaries for a particular platform/OS.
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.