Executive summary: I’ve developed a new site to help extension authors and translators collaborate; it’s called Interpr.it.
My least favorite aspect of developing browser extensions is localization. Writing the actual code to internationalize an extension isn’t so bad, but keeping the translation files up to date has always been a chore. (Localization is the process of translating software into different languages; internationalization is writing software that can be easily localized.)
The preeminent site in the extension localization space is Babelzilla. Babelzilla has been around since 2006, and it is the only site that I know of for pairing extension developers with translators. It works, but I’ve never felt that it works especially well, and when you can’t release an update to your extension because Babelzilla is down or buggy (preventing you from retrieving the latest locale files), it’s very frustrating.
Localizing Google Chrome Extensions
When I started developing browser extensions for Google Chrome, I was surprised to find that no Babelzilla equivalent exists, even though Chrome has very full-featured internationalization support for extensions – apparently, extension developers in this ecosystem are expected to come up with their own ad hoc solutions for managing their extension translations. “Ad hoc” is not a term I enjoy applying to solutions, so I decided to see what I could do to improve upon the Babelzilla experience for Chrome extension developers.
Centralizing Extension Internationalization
In developing a translation site for Chrome extensions, I had two goals:
- A full-featured API that allows developers to interact with the site without visiting it.
- A clean and simple interface for translators that reduces the barrier to entry as close to zero as possible.
With these two goals in mind, I developed Interpr.it. On Interpr.it, developers upload their extensions, translators localize them into their native language, and then developers can download the new locale files to use in their next extension update.
Interpr.it for Developers
Developer interaction is limited to the upload and download of locale files. In fact, developers can interact with Interpr.it completely from the command line via the /api/upload and /api/download API methods. (There are also API methods for translating messages and retrieving the translation history of a message.)
Interpr.it for Translators
Once an extension has been uploaded to Interpr.it, a status page is generated that shows the progress made on all of the locales supported by Chrome for extensions. Here’s an example screenshot of that page:
Each locale code links to a translation page, which is a listing of all of the messages (or “phrases” or “strings”) used in the extension. Here’s what one of those messages looks like:
There are 4 aspects to the UI for translating a single message:
- The original un-translated message.
- A description of the message from the developer, which adds context to the message.
- The placeholders in the message, used to insert information which can’t or shouldn’t be translated.
- The history of the message’s translation, which shows previous revisions and allows a developer or translator to revert changes.
(Not every message will have a description, placeholders, and a translation history.) The translator types the translated phrase in the box, and as soon as they hit the tab key (or click outside of the box), the message is automatically saved without a page reload.
Additional Interpr.it Features
Sign in/out is tied to your Google account, so you don’t have to create another username and password; it seemed like a natural fit for a site focused on Google Chrome extensions.
The Interpr.it site itself is localized using itself. (Interpr.it obviously isn’t a browser extension, but it does use Google Chrome-style JSON locale files, so it’s compatible with Interpr.it’s translation system.) To access a localized version of Interpr.it, select a locale code from the menu in top-right corner of the website, or manually type a URL like es.interpr.it.
Interpr.it will also automatically fill in any translations that have been previously completed for other extensions. For example, if a translator has already translated ‘Thank you’ into French for another extension, and a different developer’s extension uses the phrase ‘Thank you,’ Interpr.it will automatically transfer that translation. (There’s been some discussion as to whether this will backfire, but I have been unable to come up with identical English phrases that would result in different translated phrases. If you can come up with some, I’d love to hear them.)
Open for Business
If you’re a Chrome extension developer, you can upload your extension to Interpr.it right now. I’m already using it to manage localization for the Interpr.it website and two of my Chrome extensions, and so far, thirteen different translators have translated a total of 1087 messages.
After I have some more time to collect feedback from developers and translators, I plan on either adding support for Mozilla browser extensions or possibly donating code to the Babelzilla project to improve their experience for developers (if they’re interested).
If you’ve read this far, I want your feedback. Even if you’re not involved in the development or translation of browser extensions, I want to know what you think – were you not aware of the process at all? Does it sound like a problem worth solving? If you are familiar with the problems faced by developers and translators, do you think that Interpr.it is an improvement upon the Babelzilla experience? Or am I wasting my time reimplementing something that already (kind of) exists? What features would you like to see? What localization/internationalization issues do you find irritating? Leave your thoughts in the comments.
7 comments on “Improving the browser extension localization process”
Hello and Happy New Year to all localizers around the world :)
I am very pleased a top extension developer is interested in having a good translation tool, because so many times we on BabelZilla feel we are left without a real development team (let’s call a one-man-band our only tech admin), and yes we have bugs and limitations, and recently were hit by a Ddos attack (nothing to do with wikileaks though)
Here are my first personal observations, but we are already discussing about interpr.it among our little team and we shall give you more feedback soon. Of course we are interested by your suggestion by the end of the blogpost. I don’t know yet waht will come out of our discussion but note that some months ago we experimented an implementation of Chrome extension tranlation on our test site, and (to be confirmed) it seemed not a big challenge to adapt WTS code to Chrome extensions specifics.
Congrats for this implementation anyway :) with sleek and pleasant interface, I just tested it and found some good ideas:
– translation is saved automatically as soon as one field is left (I was instinctively searching for a Save button :P )
– when a translation of a string is done once for an extension, then this translation is automatically applied for other translations having the same string. Mmmh yes there can be side effects but as long as it can be manually corrected by human translator it sounds ok.
– quick easy log with googlemail account
On the other hand, of course I missed features that I am used to –I know this project is young, just a few things that come to my mind:
– the question of the “final cut” for translation (currently it is just crowdsourcing without “main translator” in charge). Who will tell: “ok this is the right final translation, let’s push it on public release? the developer is not necessary qualified in every available language.
– the question of an updating system as soon as a dev wants to add/remove strings
– glossary/googletranslate suggestions as a helping tool for human translations
– the possibility to test one’s translation before releasing. Confirmed translators of extensions always give a look at the way the translated interface is shown before releasing. Is there one “easy” way to do that on Chrome extensions?
(more feedback to come)
Great feedback, Goofy; here are my responses:
> the question of the “final cut” for translation
Do you have any stats on how many locales typically have more than one translator? e.g., if 90%+ only have one translator, then those locales are essentially crowdsourced, since the main translator is the only translator. For locales with more than one translator, how many of those ever got modified by the main translator before being approved?
> the question of an updating system as soon as a dev wants to add/remove strings
This is all handled via the upload API – any strings that get removed from the default locale are removed from the other locales as well, and any strings that are changed in the default locale are reset in the other locales. Of course, any changes are saved in the translation history, so they can easily be undone.
> glossary/googletranslate suggestions as a helping tool for human translations
This is planned, but I’m waiting for more feedback from translators before implementing it.
> the possibility to test one’s translation before releasing.
Planned as well, but still pending implementation.
> Do you have any stats on how many locales typically have more than one translator?
I can only tell you what I see for Adblock Plus on Babelzilla – locales with more than one *active* translator seem to be an exception. There are a few strong translation communities: French, Italian, maybe German (I don’t see it because I translate to German myself). For all other locales Babelzilla’s strict owner system is actually harmful because the locale owner often becomes unavailable – but the locale is “owned” which prevents other people from contributing. I suspect this to be the major reason for the quality degradation of the localizations (see https://adblockplus.org/blog/status-of-the-adblock-plus-project-spring-2010, “Localizations” section).
Thank you for tackling this. Is interpr.it source code available? My issues with Babelzilla have been growing over time and I have been considering creating my own solution for a while now. But contributing to your translating platform might give the same result with less effort spent. What I see so far looks great, a huge improvement already.
Thanks Wladmimir; the portion of your post on locale ownership describes the exact reasons why I didn’t include that feature in Interpr.it.
I will be open-sourcing Interpr.it, just as soon as I finish some documentation and decide on a source license. I’ll write a follow-up post when that happens.
I’ve developed the i18n API for the extensions, and I am glad you find it useful. I have a couple of comments wrt. the process (and this is only my opinion, nothing to do with Google):
1. When you tie translation to the message only, you may get into problems like – check, open… When translated into other languages how do you know if they are a verb, a noun or adjective? Are you going to “check” something, or are you expecting a “check” from a waiter… Open the door, or is the door open? They would look different in Serbian for example. This problem usually pops up with single words, and it’s rare with whole sentences.
Some systems combine actual message and the description into a key, where in the description you put verb, noun…
2. People like badges/trophies :), so you may get more people to join in on translation effort if you give them additional incentive…
Thanks for doing this
I knew I would forget something – it may be useful to have a button next to each item to be translated (or a check box on top – “Enable autotranslation hints” that calls, say Google translate (or some other free service) and gives a hint to a translator. I don’t know what the TOS for Google translate is so better check before using it.
Thanks for your feedback. That’s a good point about noun/verb disagreements; perhaps I’ll only use the auto-fill as a hint to translators (along with machine translation from Google or another provider).
I hesitate to do badges or trophies, if only because it seems everyone is doing badges and trophies, and it seems cliched. (Although, if everyone is doing them, there must be something redeeming about them, right?)