TransVision Is Good For Me

Well it should be good for you too

I have been using this tool for more than one year now, I think you can find it fun and useful, so I just want to share some of my personal experience here.

What is TransVision

With this glossary tool you can get a Vision of all Mozilla apps Translations for your language. It lets you dig very easily into the huge database of already existing translations.

This online service is brought to you courtesy of Frenchmozilla leader Philippe Dessante who likes playing with algorithms and scripts and explains here what is under the hood.

It is so simple and intuitive that you can see and understand immediately what it is about:

• go to this page
• click on your language letter-code (hey you should know it if your are a translator )
• drop an English string in the search box instead of the default word, click on Search and see what happens

Yes this is just simple: path to original entity, en-US string, and translation. As a translator, I am sure you appreciate to have translation in context

How I use it

Translation

That is obviously the main use I make of TransVision. I have always MozTran entry in my context menu. MozTran is a simple extension I have made to use TransVision, you can enjoy it whatever language you use (thanks to Captain Caveman’s code for automatic language detection). Just select, right-click and choose MozTran, the results page opens a new tab.

You can get MozTran on this page.

As an alternative, you can use a searchplugin.
Philippe Dessantes made one for each lang to be grabbed here on this searchplugins page !

Of course I use it on a daily basis to translate extensions but it is also very quick and efficient whenever there is some update on the Mozilla apps repository and one translator is wondering “Hey, we have to translate again this f***ing privacy policy string, I can’t remember what we chose last time…?”. The answer is just one click away.

Typo and errors chasing

My main contribution to the Frenchmozilla Team (apart from telling nonsense on #frenchmoz irc chan) is to annoy translation leaders with filing translation bugs (see my bug list on frenchmozilla Bugzilla)
I would say a solid 80% of the translation bugs I submitted were found with TransVision. here are some typical cases

mispelling

I either enter an English string in the searchbox or intentionally enter a mistyped French word (eg. déclareation,étiquté instead of déclaration, étiqueté).
I have but to read at my convenience and see where things are wrong in the fr column. Note that it is easy to check that no such typo was made when you find your language part (2nd part of the page) is just void.

missing translations

TransVision helps greatly to see where missing bits are. Here is a recent example where obviously the French part is abnormally short.

missing translation bits

translations that need to be reworded

It is much easier to browse visually a result page and read sentences to check their meaning/grammatical validity than to browse one file with a text editor or wait for strange sentences to catch your attention in the interface of a Mozilla application when using it: depending on your personal usage, it may well happen you will never come across certain strings. With TransVision you can concentrate on your language strings without being distracted by code or layout environment.

one typo means more typos of the same kind

Suppose I found a mispelled word, I re-inject it all at once in the searchbox so as to see if the little error was repeated, hence bugfixing is more systematic. Though French translation is close to professional quality, accidents may happen

Consistency checking

That is where TransVision tool is more useful than a standard all-purpose glossary.

Here we have access to all user interface for Mozilla application, hence we can have a consistent Mozilla interface. It is very important…

- for the application(s) user

- for the extensions user

…to find the same features named with the same words and sentences!

There is one special tool to be used for that, you can find it at the bottom of the TransVision page

It helps you detect when same strings (with or without same entity names) have different translations

You have just to choose which “modules” to compare. Here I choose “browser” and “mail” for Italian…

and in the output I can see sometimes different choices for the same strings (it may or may not be necessary to adjust)

More to discover

I am sure you can discover by yourself some interesting features (eg. search with regular expression or wildcard), but now it is up to you to experiment and tell everyone what usage of this tool you found, what additional features you would like to have (use this wiki page) and which bugs need to be fixed.
Comments welcome

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.