Localising the Lizard

The world is becoming a smaller place, and the World Wide Web has accelerated that process. Some hail this as a wonderful phenomenon because of the vast knowledge available to everyone and the exposure to other lives and cultures. Meanwhile, others bemoan the loss of cultural identity and language dialects.

There are tools within the Mozilla project to help you get your message to specific cultural groups by speaking to them in their native tongues. Just as the Mozilla project has captured the imagination of people the world over, its tools allow us to talk to them. Just as a matter of note, there are Mozilla advocacy sites (MozillaZine) in France, Germany, China, and Japan.

Before I get into the details of using these unique Moz tools, let me first clarify some terms. Internationalisation (i18n for short; there are 18 letters between the initial i and final n) refers to the design and development of software to function in a particular locale. Localisation is the modification of the software to meet the language of a location and the adaptation of resources, such as the user interface (UI) and documentation, for that region.

After a general overview of the internationalisation project in Mozilla, I will delve further into the details of how to go about localising your Mozilla application for specific audiences. This primarily involves UI localisation of XUL and JavaScript files and the methods employed to do this. I will then discuss the tools available to translators, focusing on the most commonly used one.

Related: Infinite Extensibility with XBL Getting Your Work Into Mozilla Tap the Power of Mozilla's User Style Sheets Extending the Mozilla Editor Mozilla News - from Meerkat

In effect, the ongoing effort within Mozilla should ensure that "English is just another language," one of the catch phases of the project.

Internationalisation and localisation projects

Mozilla 's internationalization project brings support in browsing software to a new level. Let's have a look at some at some of the high level aims of internationalisation in this context.

• Mozilla is Unicode enabled for Latin, Cyrillic, Greek, Chinese, Japanese, and Korean. Mozilla widgets and HTML rendering can support the input and display of these languages beyond the operating system (OS) limitations.
• Mozilla can be easily localised into different languages regardless of the underlying OS language version.
• Most of the Mozilla localisation work is translating DTD and Java's Properties file format, which are based on open standards.
• Localisation can be done once and run on Windows, Macintosh, Unix, and the other platforms supported by Mozilla. This is a great time saver, and indeed a cost saver, for commercial endeavors.
• Unicode enabling for other languages/script is also under development, e.g. BiDi, the display and input of text in a bi-directional format for Arabic and Hebrew.

Due to the "open source" attitude of the Mozilla community, there are more possibilities for various languages being incorporated into this product than there would be for more "commercial" browsers. The Mozilla project isn't solely about creating software, but also hosting various localisation teams and providing help wherever possible. The Mozilla Localisation Project provides these services. There's also a localised Mozilla community and discussion group which uses many languages to discuss Mozilla development issues.

Before we get to more specifics on the Mozilla project itself, however, I have a few general thoughts on implementing a web site for international audiences.

Designing your web pages to be internationally friendly

Let's take a few moments to talk about creating web pages for an international audience. Personally, I'm not fond of sites that have flags to denote links to localised versions of the pages. Flags are national symbols and are out of place here. It is the norm in the software world to use the ISO 2-character code to signify a language. These are becoming recognised amongst a wider audience. It may be a good idea to try to sniff out users' locations using a script to find their domains. However, this will not always be reliable, as that language may not be viewers' primary language or language of choice.

A useful addition to your site would be a list of translation tools available for your visitors to use. These translation tools are becoming more and more intelligent -- one example being Babelfish. Mozilla uses a service called Gist-in-Time to carry out web page translations. Try it out for yourself and evaluate the results. I think it's very impressive. It is available in the Browser via the "View-->Translate" menu item.

Cultural awareness is another important factor to take into account. Yvonne Cleary of the University of Limerick, Ireland has written a paper concerning the impact of cultural issues on the usability of a localised web site. It's clear that language is only one consideration when designing international web sites. Presentation, navigation, quantity and quality of information are amongst the other things to take into account. Try to understand your audience as best possible. Don't be afraid to solicit suggestions or strike up business partnerships to help you better serve a community that is unfamiliar to you.

Now let's look at how Mozilla can help us reach these goals.

Files for localising your package

Locale is one of the five main components of a package, the others being content, appearance, behaviour, and platform. The architecture of a package for Mozilla's cross platform front end (XPFE) is component based. It allows for the plugging in and out of the particular component you want to work, without affecting the others. Locale is one of these components.

There are four types of files that you will need to look into to localise the whole application:

1. DTD (.dtd) files, which contain entities that host the strings from XUL content files.
2. Property files (.properties), which contain string bundles that are accessed by JavaScript and C++ files
3. HTML files for certain pages installed with the application, e.g., About Mozilla
4. RDF files

Let us now have a look at these in more detail.

DTD entities

Entities in XUL are based on the same principle as is common in other XML languages. They are used as a method to reference data that has been abstracted from the content. One common motivation for using entities is for data re-use. This occurs in XUL files, but the main reason for entities is to keep separate the text contained in interface widgets such as buttons and menu items. This ensures that the actual content can remain untouched during the localisation process.

Here is a sample XUL window with a couple of menu items and a "Greetings World" display. View the full code for the file here -- note that some of the lines below may wrap in this view.

<!DOCTYPE window SYSTEM "chrome://navigator/locale/greeting.dtd">

<window id="greeting-window" title="&windowTitle.label;"
    xmlns:html="http://www.w3.org/1999/xhtml"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
    onload = "Startup()"
    align="vertical">

<menubar id="main-menubar">
  <!-- File menu -->
  <menu id="fileMenu" value="&fileMenu.label;"
accesskey="&filemenu.accesskey;">
    <menupopup>
      <menuitem value="&openmenuitem.label;"
accesskey="&fileopen.accesskey;" oncommand="Open()"/>
      <menuitem value="&closemenuitem.label;"
accesskey="&fileclose.accesskey;" oncommand="Close()"/>
    </menupopup>
  </menu>

<iframe src="chrome://navigator/locale/greetings.html" />

</window>

You'll notice that the entities are referenced using the syntax &text; and that every identifier has to begin with an ampersand (&) and end with a semi-colon (;). How is the DTD file accessed? It is associated with your XUL in the Doctype declaration. If you have a small application, the DTD files can reside in the same folder as your XUL files, but it's good practice to put them into their own locale directory within your chrome structure. Here is the DTD file for the "Greetings" window.

So to translate your XUL interface strings, you change the text that corresponds to your entity reference. Depending on the size of your application, this can be a straightforward or long-winded process. I will talk about tools later that automate the process if you have many files. If you are translating an existing language and not creating from scratch, it is a good idea not to overwrite this base language. Even if not used, it will enable another language version of your Mozilla software to be used at a later stage if needed.

Localised English Greetings window.	Localised German Greetings window.

String bundles

String bundles are ASCII text files that contain text that is accessed in JavaScript and C++ files. They commonly reside in the locale directory with the DTDs. You can set up your string bundle through an XPCOM component (nsIStringBundleService), which can be set up in your JavaScript. I'd advise you to have a look at that file if you want to find out how to set up the XPCOM component. If you don't fancy doing that yourself, Mozilla has some common utility functions that do it for you. So all you have to do is include the following file in your script:

<script type="JavaScript" src="chrome://global/content/strres.js"></script>

Then set up your bundle as follows:

var bundle = srGetStrBundle("chrome://mypackage/locale/mypackage.properties");

And the last step in the process, getting at the strings:

var greeting = bundle.GetStringFromName( "hello" );

This would retrieve the string corresponding to "hello" in your bundle file. There is an alternative method using an XBL binding. There is a binding element called <stringbundle>. It would be included in your XUL file like:

<stringbundle id="historyBundle" src="chrome://mypackage/locale/mypackage.properties"/>

Then the bundle can be accessed as follows.

var bundle = document.getElementById("stringBundle");
var greeting = bundle.getString("hello");

The advantage of this approach is that there is no overhead of including another JavaScript in your XUL file, plus the fact that the binding can be cached for quick access.

Other file types

In addition to the XUL, JavaScript, and C++ files, there may be some other files that you need to translate. In Mozilla, these include HTML files and RDF files. An example of an HTML file would be the "About Mozilla" page. Open up your Mozilla browser and type about: in the location bar. HTML files are a useful way of presenting information about your package or application, and localisation of this information can be important.

RDF is used in Mozilla as a way of accessing and storing metadata or dynamic data. The sidebar contains tabs for accessing commonly used features of the browser, such as searching and bookmarks. The notation used in the RDF is similar to the XUL entities, but in this instance they are contained inline in the file. Here are the Inline entities taken from 'panels.rdf' in Mozilla distribution:

<!DOCTYPE RDF
[
<!ENTITY sidebar.panel.whats-related "What's Related">
<!ENTITY sidebar.panel.search "Search">
<!ENTITY sidebar.panel.tinderbox "Tinderbox">
<!ENTITY sidebar.nc-panel.stocks "Stocks">
<!ENTITY sidebar.panel.client-bookmarks "Bookmarks">
]
>

If you go about translating the whole Mozilla application, you'll find that there are some words or phrases that will remain untouched. These will include terms that are used for branding, or universal terms of web browsing such as "Bookmarks," "Tasks," and "Tools." In some instances, the choice to translate some of these terms is purely subjective.

Tools

It became clear early in the project, especially among outside developers who were localising Mozilla or applications built on top of Mozilla, that the translation process was too time consuming. It involved hand-editing the files to extract the strings, translating them, and then inserting them back into the relevant files. As a result, some enterprising people built tools to automate the process, and in the meantime have made many friends in the community.

MozillaTranslator and MozExpTool are the two primary tools, and I will focus on the former: MozillaTranslator. This is a Java-based application that was written by Henrik Lynggaard in Denmark. For the latest download, head over to MozillaTranslator.org. This site has the complementary service of hosting language packs for various builds of Mozilla. I can see it evolving into a one-stop shop for the Mozilla translator.

Here is a quick tutorial to get you started:

1. Select File-->Manage Installs.
2. Press "Add" in the dialog to add a package.
3. Give it a label (for your own use).
4. Point to the path chrome\en-US or chrome\en-US.jar (replace the path with your own for your Mozilla application locale) within the Mozilla build.
5. Exit the dialog.
6. Select File-->Update Install.
7. Select Edit-->Chrome View once the update has finished, and you should see the component structure and be able to choose fields for viewing

Chrome view in MozillaTranslator (click for full-size view).

At this point you can edit the text straight from the chrome view. There's also the option to bring up an edit window for a selected phrase, which will give you all the possible editable fields in one window. There's an advanced search feature, something that's very useful if you're looking for a piece of text in a heap of files. Another of the more advanced features includes the ability to read from and write to a JAR archive.

A JAR archive is a compressed version of a chrome component, the standard now being used in Mozilla. You can create a cross-platform install (XPI) file for your locale component using MozillaTranslator. These are essentially compressed files which contain the JAR archive and an install script that is a small JavaScript file. This enables easier distribution and shields the translator from the technical workings of Mozilla. That's really the basis of the program, to make the translating process as straightforward as possible for those new to Mozilla and for those only concerned with working on the text to be translated.

Double Dutch

So, while this is not a call to bring Mozilla to the world, it should give you a firm basis to start localising the software in your own language. You can find out more here about the projects currently underway to localise Mozilla.

If you've already been playing around with localising the front-end of your Mozilla program and would like to do more, or perhaps you would like a version of Mozilla in your own language that is not already represented, here are some things to keep in mind.

First of all, get your translated version hosted either on MozillaTranslator.org or mozilla.org, or preferably both. Keep it up to date and make people aware of it, posting notification on the relevant newsgroups. Tools will become more advanced as time progresses, so be sure to monitor new releases of MozillaTranslator or perhaps the appearance of other tools.

Mozilla is raising the standards for internationalised software. This is in part due to the open source nature of the project and the demands of developers that come with that. Turn this on its head and the benefits become clear: A wider development community opens up the chance for more translators from more regions in the world. This international attitude accompanied by good design goals and implementation makes the Mozilla software truly sans barriers.

Brian King is an independent consultant who works with web and open source technologies.

Related:

Infinite Extensibility with XBL

Getting Your Work Into Mozilla

Tap the Power of Mozilla's User Style Sheets

Extending the Mozilla Editor

Mozilla News - from Meerkat

Discuss this article in the O'Reilly Network Browsers Forum.

Return to the Mozilla DevCenter.

Copyright © 2009 O'Reilly Media, Inc.