2014 – My Q4 [:flod]

FirefoxOne of my many resolutions for 2015 is to blog more, both here in English and on my Italian blog, which just turned 10 last September.
Keeping a diary of what happened in the last months can be useful, and it’s definitely a good exercise for me, so I’ll try to make a habit of posting a summary of my quarters like my teammate Pascal does.


I probably spent most of my last quarter working on mozilla.org updates. My job, together with Pascal, consists in checking new pages for localizability issues at an early stage, extracting strings in .lang files, exposing them to localizers and pushing content to production. Luckily, on the other side there’s a wonderful team of people who help us making sure that localization is always treated as a first class citizen.

The new home page design went live in October, localized in 33 languages on day one (57 as I write this post). That’s a huge accomplishment.

Ignoring smaller updates, this quarter we also had the new Firefox for Android page (42 languages), the redesigned Get Involved page (25 languages, with some bumps on the road), and the new Firefox Developer Edition landing page (34 languages).

And then this tiny thing called #fx10 happened.

Firefox 10th Anniversary

This was an interesting and exhausting experience. For example in order to localize the UI Tour (“Privacy Tour”) for 33.1 I had to manage communications with 26 teams using direct emails. And then organize the localization of subtitles for this video (I’ll talk about this in a separate post, long story). Everything trying to disclose as little information as possible to the public before the launch and avoid spoiling the surprise.

To give some numbers: we usually ask for 2/3 weeks for small localization projects, at least 4 weeks for bigger projects that require work from all ~90 locales supported across platforms (last case was Australis launch).

In this case the longest deadline was 3 weeks (privacy tour), most of the material became available 2 weeks from launch, with some edge cases (48 hours), a lot of changes, unplanned material and averted crises (huge shout-out to Erin Lancaster for coordinating so many teams and initiatives).

Size of the work requested to localizers: a rough estimate varies from a minimum of about 140 strings/1000 words, to about 330 strings/3000 words for bigger locales.

Internal Tools

To track the localization status of web parts we rely on three different tools:

  • Langchecker: analyzes SVN repositories hosting strings in .lang format, provides status dashboards, error checks and feeds external tools with results.
  • Webstatus: same as langchecker, but for external products/websites (SVN/Github) using Gettext files.
  • Webdashboard: it’s the source used by localizers to track pending work (how many strings are missing, deadlines, errors, etc.), displaying information received from langchecker and webstatus.

These are some of the improvements introduced in the last quarter.


I added support for a raw file type, currently used for text files. Unlike .lang file, where we can determine the exact status of localization (translated strings, missing, errors, etc.), we can only do minimal checks for this kind of files: does the file exist in locale X? Is it mandatory or optional? Was it updated before or after the last reference update? The main usage for this is to track localization of autoresponders for the new Get Involved page.

Also added command line scripts to import strings in .lang files using Transvision API, and improved the code detecting errors in translations (e.g. missing Python variables).


Besides displaying information about raw files, I focused on improving a very useful feature added last summer by our intern Théo, called “Project View”. Basically we can display on a single page the status of several files scattered across different repositories (example) and share it with other teams.


I didn’t have much time to work on Transvision this quarter, but I managed to land a change that I consider really important: now the list of supported products and supported locales for each product is fetched from an external source. The practical result is that we don’t have to release a new version of Transvision to support Gaia version X or add a new locale on Aurora, reducing the time necessary to deploy these changes from weeks or months (new manual release) to less than 24 hours (automated cronjob).

I also worked on a view to display “unchanged strings” (i.e. strings identical to English), and some small refactor/clean-up changes.

One my goals for next quarter is to figure out with other team members a plan/schedule to release more often.


Part of my job is also to take care of productization (p12n), which means landing settings for new locales, as well as organizing mass updates (e.g. switching Wikipedia to SLL) and making sure that we don’t ship anything broken.

Last quarter I did a complete rewrite of the tool I use to extract information from all repositories. The original code was never meant to be shared; for example I realized how counter-intuitive the data structure was only after trying to explain it to another person. It’s still clumsy Python code written by someone who never saw Python until two years ago, but now with tests 🙂

The same tool is at the base of this view on Transvision, or images like this one (all searchplugin images we’re shipping on Firefox Beta across locales).

Firefox Beta Images


As part of my daily job I also check all strings landing on master/trunk branches for Gaia, Firefox and Firefox for Android, and file bugs for any localizability issues. Some interesting things happened there (e.g. the new search UI), but that’s a discussion probably worth a different post (and more thinking on my side).

I also briefly helped Mozilla Foundation organizing the localization process of the EOY fundraising campaign. I really hope we’ll manage to organize this better next year, and involve localization teams in the process if they have resources to help.

Comments are closed.