Translating Adblock Plus: Dumping Babelzilla for Crowdin · 2012-11-09 13:40 by Wladimir Palant

The Adblock Plus project has been using Babelzilla for translations for more than six years. Yet, time has come to change that. Two days ago I moved the translations for all my extensions from Babelzilla to Crowdin, meaning Adblock Plus, Element Hiding Helper and JavaScript Deobfuscator. This was preceded by a lengthy pilot phase with the Customizations for Adblock Plus extension and recently also Adblock Plus for Chrome.

Why change to a new platform?

Babelzilla helped us a lot, managing more than 40 translations for Adblock Plus alone wouldn’t have been possible without it. Yet, I’ve been dissatisfied with the service for quite some time (mentioned it first time two years ago). Reasons are:

What about alternatives?

I’ve looked at lots of different options to manage our translations. There was a thought to use Anwiki but it has lots of issues of its own. Pootle was a consideration but it didn’t look like a great solution (e.g. very much geared towards .po files) and we would still have to host it ourselves.

For a while it looked like Tim Babych’s Adofex would be the way to go, especially after Babelzilla announced plans to move to that platform. So early this year I approached Babelzilla admins with some thoughts on how to make that migration progress faster and generally make Babelzilla a more reliable platform. After not hearing back I finally realized that depending on somebody’s hobby project with something as important as localization might not have been the best idea.

What does Crowdin have to offer?

I came across Crowdin in July thanks to a hint from Thomas Greiner. I decided to try translating the Customizations extension there, one that wasn’t on Babelzilla simply because I was afraid of uploading it there due to all the bugs. Here is my experience so far:

Bugs? What bugs?

Crowdin’s support for the DTD and properties file formats isn’t ideal, they manage to extract the strings from these files all right but not the comments. This is not really surprising given that the way how comments in these formats should be matched to strings is “underspecified”. Fortunately, Crowdin supports a number of other file formats as well. So my solution was to convert all locale files to the Chrome-style JSON format on upload and back on download. This format has the advantage of a well-specified description field and it is generally a lot easier to parse due to the availability of good JSON parsers for basically any programming language.

Another major issue are access keys. Crowdin doesn’t always display the strings in the order in which they are listed in the file, in particular untranslated strings are always listed first. This has the side-effect that locating the label for an access key is sometimes non-trivial. Which is of course a side-effect of translating labels and their access keys as separate strings — not a good idea in the first place. I consider merging them into one string for the translations in future.

There are also some minor annoyances like there being a limited number of supported languages (I requested adding all the additional languages supported by Firefox but that appears to be non-trivial). Or the not quite yet mature placeholders support. Or the overly crowded (pun intended) translation interface.


Comment [3]

  1. Goofy · 2012-11-09 17:14 · #

    We are happy you finally found a better toy to play with. Good luck, Wladimir.

  2. Eric Jung · 2012-11-12 19:02 · #

    Hi Wlad,

    Thanks for the post. Lots of the top 25 addons have been looking for alternatives. I expect crowdin will get a lot of new business because of your choice.

    So my solution was to convert all locale files to the Chrome-style JSON format on upload and back on download

    Is that open-source? If not, are you willing to share it? FoxyProxy is going to try crowdin. It would be nice to follow in your footsteps re: JSON conversion. We use ant (build.xml) and jenkins for our build system, so JSON conversion and upload/download via API would be a great fit.

    Eric Jung

    Reply from Wladimir Palant:

    Yes, it is open source, part of our build system in fact ( Not sure how much you can reuse that but the important functions are parseDTDString and parsePropertiesString as well as toJSON/fromJSON.

  3. Crowdin Team · 2012-11-13 17:47 · #

    We will be happy to provide you solution that will not require any additional tools to manage your localization files. Can you please ping us at and let us know the bugs you experience with DTD files?

    We’re online and happy to help.

    //Crowdin Team

Commenting is closed for this article.