Two very useful new localization related features have been added to AMO (addons.mozilla.org) recently.

Locale statistics

Add-on statistics pages are now capable of listing the total number of daily users by locale. Awesome.

Take a look at my stats for Flagfox, as an example:

Flagfox stats as of this posting

This means that extension developers are now armed with the data to actually request specific localizations that their users would use but currently do not have.

This new set of statistics is available by selecting “Locale” in the drop down menu on the left. The other new feature in there is the ability to break down downloads by method, which too is quite helpful. Note that while statistics tracking is available for all add-ons, the page must be set to “public” mode by the developer to be accessible by others.

Locale completeness checks

The AMO add-on validator now has a test to automatically check for incomplete locales. (see announcement)

L10n validation

On upload of an extension file to AMO, the add-on validator will now warn you if it has missing or untranslated strings. You can also (re)check your files via the “Validation” column in the “Versions and Files” view in the developer control panel. (files checked before this test was added need to be rechecked manually to see new results) Logged in non-developer users are also free to upload XPIs to check here.

Of course, as with some of the other warnings in this thing, please remember, it’s only a warning. Don’t worry too much about rejection from AMO merely for having some untranslated strings. Flagfox, for example, has 1807 “unmodified translations” in 18 different locales. Granted, I’m a special case here with hundreds of different country names that need to be localized, quite a few of which use the same word as in English. (if you package correctly it all gets compressed out nicely in the end so it doesn’t waste installer size) So just keep in mind that your mileage may vary.

Many thanks to AMO for these very nice and useful new features.

It’s time to exorcise contents.rdf

What are contents.rdf files?

Junk from a bygone era. When writing a Mozilla extension you need to tell the application where and what your extension’s files are. Since Firefox 1.5 (Gecko 1.8) it’s been a simple matter of writing a chrome.manifest file, but before that there were contents.rdf files. You needed a contents.rdf file for your overlays and another one for each locale. An example:

<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:chrome="http://www.mozilla.org/rdf/chrome#">

  <RDF:Seq about="urn:mozilla:package:root">
      <RDF:li resource="urn:mozilla:package:myext"/>
  </RDF:Seq>

  <RDF:Description about="urn:mozilla:package:myext" chrome:name="myext"/>

  <RDF:Seq about="urn:mozilla:overlays">
   <RDF:li resource="chrome://browser/content/browser.xul"/>
   <RDF:li resource="chrome://navigator/content/navigator.xul"/>
  </RDF:Seq>

  <RDF:Seq about="chrome://navigator/content/navigator.xul">
    <RDF:li>chrome://myext/content/overlay.xul</RDF:li>
  </RDF:Seq>
  <RDF:Seq about="chrome://browser/content/browser.xul">
    <RDF:li>chrome://myext/content/overlay.xul</RDF:li>
  </RDF:Seq>
</RDF:RDF>

and for each locale, a different version of:

<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:chrome="http://www.mozilla.org/rdf/chrome#">

    <RDF:Seq about="urn:mozilla:locale:root">
        <RDF:li resource="urn:mozilla:locale:en-US"/>
    </RDF:Seq>

    <RDF:Description about="urn:mozilla:locale:en-US" chrome:name="en-US">
        <chrome:packages>
            <RDF:Seq about="urn:mozilla:locale:en-US:packages">
                <RDF:li resource="urn:mozilla:locale:en-US:myext"/>
            </RDF:Seq>
        </chrome:packages>
    </RDF:Description>
</RDF:RDF>

It’s a mess. These days you do the same thing in a chrome.manifest file with one line for each locale and overlay, instead of dozens and dozens of files of RDF gobbledygook all over the place.

Great. It was replaced 4 years ago…

Not quite. SeaMonkey 1.x still uses install.js scripts and this whole archaic system. Its engine is extremely out of date. If you want your extension to support SeaMonkey 1.x, you’ll need to write your own god-awful install script (what, do it automatically? you must be joking) and dozens of different contents.rdf files. Each locale will have its own contents.rdf and will probably scare your translators. It’s a mess that most extension developers don’t want to write or maintain, but… there is hope: SeaMonkey 2. After years of rewrites, the so-called “Toolkit Transition” brings the SeaMonkey code base into the modern world with support for all the sane extension stuffs you’re used to in other Mozilla applications. You can write one extension that works in both Firefox and SeaMonkey without having to do too much special. SeaMonkey 2 should be released soon, so we will finally be able to retire this kludge. There might be some other obscure application out there that still uses these, but I think it has almost entirely gone the way of the dodo at this point.

Why do I care?

Again, it’s a mess. It’s added complexity that is long since obsolete and hasn’t been recommended since Firefox 1.0. Furthermore, for Firefox 3.6 (Gecko 1.9.2) the entire functionality has been removed.

If you’re an extension developer:

If you’re still in the stone age and relying on this system for chrome registration in newer applications then you’ll need to switch to a chrome.manifest for your extension to work in Firefox 3.6 and later. It’s not hard. Firefox 1.5 or later will even make one for you if you install an old extension into it. You can leave it in to support really old applications and it won’t hurt anything if you’re also using a chrome.manifest, but eventually you’re going to want to clean it up and get with the program.

If you’re just stringing along your install.js and contents.rdf files for SeaMonkey 1.x support, then it’s time to start thinking about dropping it. SeaMonkey 1.1 is almost 3 years old now. SeaMonkey 2.0 will be out soon and it’s lightyears ahead of its predecessor in many areas. Many extension developers have already started dropping SeaMonkey 1.x support in favor of 2.0 and you’ll probably also want to do so at some point.

If you’re an extension user:

With various major upgrades and the death of install.js and contents.rdf, writing extensions for SeaMonkey is no longer ugly. More and more Firefox and Thunderbird extensions can be expected to gain SeaMonkey support in the future because developers won’t have to handle things too drastically differently anymore.

If you’re an extension translator:

If one of your localizations still has a contents.rdf file for you to “translate” (i.e. change all the instances of “en-US” to your locale’s ID), feel free to point the extension’s developer here. Translators were never intended to have to deal with these things in the first place. All it does is add confusion and a rather unneeded extra hoop to jump through.