Last quarter, the l10n-drivers set out to document the steps necessary to make a web site or web application localizable (i.e. designing a project so it can be translated and localized).  All too often, we found ourselves providing feedback on projects that had begun with the intention to reach a global audience, but had not been designed to scale at the intended level.

To illustrate our point, we decided to choose a real life example that we could go through with a team of project managers to document the steps necessary to make a project localizable.  What we needed was a pilot project that had launched quickly to test a concept and see if the idea had enough global appeal that it would require localization.  We chose Get Personas as the test case because it fit our criteria perfectly.  With this project, Mozilla Labs had a site that had launched to prove its concept.  Mozilla Labs often moves quickly and may not have the time or resources to map out just what of its many projects might take off since some of them may not.  In this case, Personas quickly appeared to have global appeal and a need for l10n, but it contained project design flaws that did not have localization in mind from the beginning.

After working for the entire quarter with Mozilla’s Ryan Doherty, who was charged with making the site localizable, Staś Małolepszy, with Pascal Chevrel’s guidance and some from me, compiled all that we learned into several documents now hosted on the Mozilla wiki and on the Mozilla Development Center.  Our intended audience for these documents is marketing and web dev folks.

If you’ve ever wondered what it takes to make a website localizable so it can scale to a global audience, please take a look at this wiki page and its links to other important documentation.

We’ll walk through the piece of this wiki page in more detail in a few forthcoming posts.

ShareThis

Here’s a little anecdote on why I believe that.

Although it may be known by some, we try to ship each localized version of Firefox with a language dictionary so users can have the same spell-checking functionality in their native language that en-US users have when writing web mail, blogs, or whatever.  Sometimes, licensing issues determine if we can ship Firefox with a particular dictionary.  If an open source license prevents us from shipping that dictionary, the dictionary still can be created as an add-on and offered to end users from our Add-ons website via the Getting Started page.

This was the case in Denmark.  When a license prevented a dictionary from shipping, our localizers thought creatively and suggested that we feature the Danish add-on on the Getting Started page.  The experiment resulted in a bit of a surprise.  The link became the most popular click-through on the page!  See the attached image I mocked up.

The above image is a “heat map” from the month of May that shows total number of user clicks and the ranking of those links out of the total number of points of interaction on the page.  You can see that the dictionary ranked one out of twenty-eight with 2,216 clicks.  I’d like to think that over 2,000 users added the dictionary after clicking.  When you check the download statistics on the add-on’s page, you can see that it is quite popular.

Where else could we see this benefit to dictionaries?  I suspect that it would be useful to present dictionary add-ons on the Getting Stared pages where bilingual users are prevalent.  Don’t hesitate to make the suggestion to us and we’ll make the change if feasible. And, if you are a localizer who faces a licensing conflict with a dictionary, please let us know.  Let’s put it on the Getting Started page.

ShareThis

Communication improvements

• Placed a highly visible subscription link to the RSS feed so updates to relevant bugs are seen immediately by localizers
• Began sorting feeds chronologically with better description of tasks
• Fixed a bug on feed page so that the feed now leads directly to a locale’s page
• Added “last update of data” information on pages
• Improved the readability with CSS and template changes

Organization of locales

• Added the metalocale ‘es’ Spanish for tracking of projects shared by all Spanish-speaking teams (mostly marketing sites and support)
• Added the locales es-CL, ms, or, rm, ta-LK

Projects views

• Added support for a bug to belong to multiple projects in tracking sections
  • ex: Major Update for 3.5 is displayed in the “3.5 in-product pages” and “Major updates” projects
• Added new subsections for Firefox 3.5 release for tracking
  • Projects and sections can be added/removed editing a config file, useful for short term projects like mini-sites

New tool  

• main.lang checker, which I blogged about in the past
  
• Warns the localizer of UI strings missing or identical to en-GB (as the reference locale) on mozilla.com/mozilla europe/mozilla messaging
• Added main.lang checker data to the web dashboard
  • if main.lang files are out of date, it is displayed in the rss feed and the web dashboard page

Other

• Added raw json output of all bugs (http://l10n.mozilla.org/~pascalc/includes/projets/dashboard/data/data.bugs.php?json=1)
• Externalized and shared with Stas list of bugs and progress
  • http://granary.stage.mozilla.com/
  • Not sure if it is going to be used all the time as it is slow to update and makes the dashboard code more complex as well, but it will allow other people to update the web dashboard when Pascal is busy with other items

ShareThis

For an example, let’s take a look at French locale’s page.  Here you’ll see a section titled “Missing strings.” and another named “Strings identical to English.”  At the bottom is a link to the French translations of the strings in the fr main.lang in SVN.  At this page, a localizer has a basic snapshot of the state of their team’s web l10n.

I see some quick and direct benefits:

1. Localizers can now see very specifically what l10n strings need examination
2. New localizaiton teams who have finished localizing the Firefox product can see the the web localization tasks ahead
3. Mozilla improves its communication regarding what specifically needs to be accomplished for a version to become official

This is just another starting point.  We’ll have to work on unifying all of the recent improvements and forthcoming changes we’ll be seeing over the next couple weeks and months.  But, please find your locale of interest to see what needs to be investigated and possibly translated.

Thanks, Pascal.

ShareThis