Tuesday, September 27, 2011

How did I (almost) automate Mozilla's localization process using Narro

Initially, I do these manually:

  • hg clone [mozilla-repo] mozilla-repo
  • setup mozilla-repo/.mozconfig file and create mozilla-repo/../l10n and mozilla-repo/../build/
  • depending on the server I might also need to adjust some environment variables

After this is done, luckily with aurora and beta we have stable branches so I just need to pull and update. There's a scheduled process that runs

  • hg pull
  • hg update -C
  • python client.py checkout (for thunderbird / seamonkey )
  • make -sf client.mk configure // not launching the whole build process, just getting the files needed to build a language pack

After this process runs, there's a Narro import process that processes the en-US files and imports the files that are changed since the last import for all projects, all languages. This basically takes formats like dtd, ini, properties, html, po and parses them to allow a Narro user to translate them by just entering the translation in a textarea.

Each time a user exports a project, an attempt to build a language pack is made. To do this, I do:

  • cd mozilla-repo/../build/[component_name]/locales
  • make -s langpack-xx

It would be a lot easier if I didn't have to pull the entire repository to build a simple zip file. No easy way around it, too many variables. This works and helps with testing.

Now if the Narro user is satisfied, can choose to commit to Mercurial. I managed to include that in Narro, although it's quite difficult since you have to commit with your SSH key. So you can do that in Narro too.

After this, the next step is the Mozilla dashboard and a nightly build. The Mozilla dashboard uses a python script, compare-locales that does some general quality checks that I wouldn't want to reproduce in PHP. So I can run compare-locales myself and not wait for the dashboard. This is quite complicated because compare-locales wants as parameters the directories that need to be translated, to have those automatically I would need to search for l10n.ini files and parse them. Right now I hardcoded them for the major projects (Firefox, Thunderbird) and it works fine.

Now I have to wait for the next nightly build, and I'll have that as a link on the project list thanks to a Narro plugin.

Once the nightly was tested, I can go to the Mozilla Dashboard and sign off with my latest Mercurial commit.

So the only thing that is not automated is the sign off; that's doable too, but not a priority.

What this complicated process gets me is a Narro instance that automatically picks up new texts and changes, I or whoever can translate them, export them and commit them without the need of having anything else than a browser.

Just having the possibility to translate, export and get a language pack that easy is gold to any newcomer.

Now I'm trying to remove the manual part from this process so you can add a new project from Narro without having to go into the console. Even if it's a one time process and it doesn't change that often.

Oh, don't think that other localization projects are different just because they use gettext. You'll always have at least the problem of getting used to SVN, CVS, Mercurial, bugtracker or whatever before you commit your translations. I can't change each project. But building a tool that can deal with these situations is something that I need and use.

No comments: