The world is full of people who don’t read English, so it makes sense that your application should cater to more of the world than just them. Firefox provides a means to display these other languages through its use of locales.

There are a couple of ways to play with locales, but the easiest way is the Quick Locale Switcher plugin.

Se-IDE currently ships with support for four locales

  • en-US – US English
  • fr-FR – France french (as compared to Canadian french)
  • ja-JP – Japanese
  • pt-BR – Brazilian portuguese

The reason I list these here is that, like most things, you need to make a chrome.manifest change for each locale you support. And since the plugin your custom plugin supports those four, yours should too.

locale preflight en-US chrome/locale/en-US/
locale preflight fr-FR chrome/locale/fr-FR/
locale preflight ja-JP chrome/locale/ja-JP/
locale preflight pt-BR chrome/locale/pt-BR/

Now, Firefox knows where to look for its language strings.

Believe it or not, if you have been following this series you are already used to making use of the localization framework. Recall that we have been putting the following line in our .xul files?


<p>
Through a bit of internal magic, the ‘locale’ part of that gets switched into whichever locale you have selected so in my ‘normal’ case the url is really <i>chrome://preflight/chrome/locale/en-US/options.dtd</i>. With that url loading in the overlay we can now pull locale specific strings from it.<br></br><br></br>
Right now, it only has one string in it.<br></br></p>


<p>
To reference that string you use the entity name preceded by a & as shown in this snippet of overlay.</p>
<hbox align="center"><label control="name" value="&performpreflight;"></label>
  <checkbox id="perform" preference="pref_perform"></checkbox></hbox>
<p>
Ideally, <i><b>every</b></i> string that is presented to the user in your overlays would be handled like this. A good way to test this is through a technique I call <a href="http://adam.goucher.ca/?p=510">LOUD</a> which I will let you research on your own a bit.<br></br><br></br>
But referencing DTDs in xul is only half of the L10N story as far as our plugins go. Plugins are a combination of XUL and JS.<br></br><br></br>
The way you localize the JS is very similar to the XUL only instead of using .dtd files you use a .properties file. Now my <i>Preflight Checks</i> plugin is still too simple to have JS that displays something to the user, so I can’t really make use of this. But essentially, this is what you need to know…</p>
  • Property files have the syntax of key=value
  • In your overlay, use the stringbundle element to inject it into the DOM 
      <stringbundle id="options.strings" src="chrome://preflight/locale/options.properties"></stringbundle>
  • Get a reference to the bundle from the DOM and then extract the string 
      var strbundle = document.getElementById("options.strings");
  var nofilesfound=strbundle.getString("notFoundAlert");

That’s it. It can be a bit of a pain when creating screens to now have to put text into multiple files when working, but it is an absolute pain to have to find all your strings after the fact, so just get in the habit of writing L10N clean code from the start.

Oh, and here are two links that you will want to have handy when doing this step are