Thimble has been Localized

BIG NEWS EVERYONE!!! *drumroll* – Thimble has been localized!

I have been working on this project for over a year now so I am very excited that Thimble has taken this giant leap forward in expanding its global outreach. Take a look at the post on the Webmaker Blog that talks about this amazing new feat. Here, I will talk a bit about some of the technical challenges involved in the localization process. Fair warning, there is a lot to talk about.

In general some of the main issues that we needed to figure out were:

  • What did we want to localize?
  • How would we engage the community?
  • What frameworks/technologies should we use?

What did we want to localize?

From a technical perspective this was mainly relevant because of how much work it would involve in localizing each component. It was important for us to prioritize. It was as simple as asking ourselves the question – “What would you use Thimble for?” or a less loaded question – “What are the main features of Thimble?”. Once these questions were answered, it was easy to figure out what needed to be localized. Some were obvious (for e.g. the homepage strings, strings in menus, etc.) while some needed a decent amount of consideration (for e.g. the optional extension HTML and CSS Linter, the default name when creating a new project). In the end, we brought it down to a list and being an open-source project hosted on Github, we filed separate issues on it. We decided to de-prioritize less-used features such as HTML/CSS documentation help and the HTML/CSS linter.

How would we engage the community?

Getting translators to work on Thimble was actually a fairly easy undertaking. We decided to use one of Mozilla’s fairly new projects called Pontoon. There were several advantages for using this approach. The most important ones were, firstly, we could rely on our vast Mozillian community to translate for us and each translation is subjected to a fairly rigorous review process, and secondly, Pontoon is a neat tool – it allows in-place translation of content. Take a look at this:



This made it easy for translators to click on most text blocks and edit the string in the user interface itself. Pretty cool eh? Also, for those curious, translators can also click on the hamburger menu on the left and edit the strings there (useful for strings that can’t be obviously seen in the interface for e.g.). The process itself was incredible! Once we had Thimble on Pontoon, translations came in at light speed. We had translated 100% in 4 languages within the first day. Now, we’re localized in 16 (and counting)!

What frameworks/technologies should we use?

This was a tough one. A plethora of technologies are always available to experiment with but choosing one (or a few) is often the challenge. Many current Mozilla products rely on React as their underlying framework and integrating React-specific l10n frameworks was easy. Hence, one consideration was to rewrite Thimble in React. NO! A good way to summarize this decision was that we were rightfully afraid of the unknowns faced when experimenting with a complete overhaul. Instead, we decided to go with a tested framework that we used in some of our previous applications. It was more of a combination of two different technologies really – node-webmaker-i18n + Nunjucks. The former was used as the localization library for our server (it integrates really well with express.js) while the latter for rendering localized strings into our HTML pages. What about the client JavaScript? We use a bunch of strings there that are dynamically injected into an HTML page. We quickly dismissed the idea of using RequireJS’ i18n plugin (we use RequireJS for our client-side JS). It seemed like too much work to get it set up (it requires a pretty strict architecture, hence the name I guess). So instead, we generated a localized version of each script for each locale. So, if you had 10 locales, each script would have 10 versions. We decided which version to give the client when the request comes to the server. All the strings that needed to be localized in the client were simply rendered using Nunjucks (take a look here for a good example).

But where were our strings? Well, that was another challenge on its own. Pontoon expects a folder called locales in the root of your Github repository that will store one folder per locale. Each locale folder will have a .properties file where strings will be stored. node-webmaker-i18n on the other hand expects JSON files instead. Hence, we had to write a script that would do the conversion for us.

Things got a lot more complicated when we had to deal with Brackets. A bit of context – Thimble is actually made up of two main components/projects namely which is the main entry point and host of the Thimble application, and Brackets which serves as our editor with the live preview feature. Being two distinct projects, they were stored in two different repositories on Github. Moreover, Brackets already had an existing localization framework which we needed to work with viz. RequireJS i18n. Those who have worked with RequireJS might already know that integrating anything into it is a nightmare. The main challenge here was to somehow merge our strings in with the existing Brackets strings. But we faced the same issue as we did with Thimble, we need to turn a .properties file into a RequireJS compatible string file. This was a lot more complicated because we had to figure out a way to convert CommonJS (our strings in JSON) into RequireJS (Brackets’ strings). Turns out, there isn’t a lot out there that does this. Consequently, after spending days on this, we wrote ANOTHER script that would use Nunjucks to create the RequireJS formatted files from the .properties files based on a RequireJS template (that we designed to be similar to what Brackets already uses). This worked!

Yay! A ridiculously huge number of challenges later, we figured out a good architecture for this! Of course, we did have another big challenge ahead of us – Pontoon was not able to commit or read strings from the Brackets repository because it was unable to deal with the complexity of Thimble (a single entry point) was actually two projects. Stay tuned for my next post to learn about how we got past this (HINT: It involves Travis CI).

So, we got a lot accomplished in two months. I personally thought that it would take only about a month but accurately estimating completion time was never really my forte.

I’m proud that Thimble is now officially a localized application but as with all software, this is just the beginning. Still ahead, localizing starter projects, engaging global communities, figuring out right-to-left languages, etc. I’m excited for all of it! / March 16, 2016 / Thimble
Tags: , , , , , ,


  1. Kieran Sedgwick - March 21, 2016 @ 8:21 am

    Great work! The future looks bright for Thimble.


Leave a Reply

Your email address will not be published / Required fields are marked *