Startup Localisation Plan or How to Get Your Product Available in Multiple Languages for Free

Since the very beginning at Eliademy, we knew that we have to focus on the non-English speaking countries. But instead of talking about our “internationalization” strategy and getting help of “consultants” (we are company from Finland after all), we just went on and did it.

I was lucky to have a bit of experience from running N9 localization project for MEA, but without Nokia paying the bill of localization experts, engineers and QA, our team needed to come to come up with a new cost-effective “startup” way. The result — roughly a year a year after launch Eliademy was available in 32 languages with a total “localization” expenditure at 110 euros. This is how we did it.

1. Set up proper development process

Even though in a startup you are constantly working against enormous statistical failure rate, building a product with a long term perspective in mind always pays out in the end. From day one we had a complete ban on hardcoding text anywhere in on the front-end — all messages, labels, and buttons have to be allocated via logical strings.

For a PHP/JavaScript combination, it usually results in having a separate file with an array of string for each language — here is how english.php would look like

$str = array(
“button_signup_now” => “Sign up now”,
“label_features” => “Features”);

And a call to this particular string whenever this page is assembled:

<a class=”btn btn-large” href=”signup”><?php echo(get_string(“button_signup_now”)); ?></a>

Keeping all English/master strings in a centralized place also helps a lot to free some time for developers since UX designer or a product manager can add new strings directly and simply reference them in the spec.

For long term maintainability, it also pays out to follow a simple naming convention. In our case, it was always type_actionname_yourimagination.

2. Choose the right platform

Initially, you can manage everything just with few localization files, but as the amount of text in the application/service grows (let alone constant A/B testing of meaning), version control becomes a hurdle. This is where you need to start thinking about using a proper solution.

There are few choices out there. You can build your own interface (like the guys from UserVoice), get a commercial Transifex or even integrate with pay-per-view services like Localize.js. Problem is that all of them require a bit of a financial contribution.

After doing some research we decidet to use Pootle — it is open source, relatively lightweight (Python/Django), has a pretty straightforward UI and requires a minimum level of maintenance. It is build for the web and has few very basic community management tools that got handy a bit later. What is most important Pootle absolutely free to use.

The only downside — it requires a certain degree of integration even though it support PHP arrays (and many other forms) our of the box. If you don’t want to manage localization files manually, you will need to make a script that picks up.php string files from your codebase and send them to Pootle; and vice versa script to get new translations back to the code. Later one can be done as an automatic pull request just to make sure new translations don’t accidentally break your production code. Pootle documentation extensively covers all of it.

As a result, you get a self-hosted public platform (translate.eliademy.com) that allows virtually anyone to contribute a word, a sentence or the whole new language for your product.

3. Get the first example out

Launching a localization website for a service that was used only by a few thousand naturally didn’t result in anything. We needed something to give it a push. I took a lead of getting Russian translation out, a couple of my colleagues started to work on Finnish and Spanish versions.

However, running localisation completely in-house turned out to be quite a time intensive and usually prevented us from focussing on the product development. Then we got another idea — reach out for a professional localization agency and ask for a quote. Here it is important to remember that while such agencies charge per word, they staff is usually located in the country of their language. And in our case, while the quote for Swedish translation was well over 1000 euros, a professional Polish localization would cost almost 10 times less. At that point of time we started to get lots of traction from eastern Europe, so paying for it was a no brainer.

Still I was not entirely happy with the amount of overhead such approach needed. Normally we would follow 2 weeks sprints, thus, we needed to create strings for all new features, send them (along with changes to existing ones) to localization agency, get the .po file back and upload it manually, run scripts to sync it, release it and only then ask localization team to check that all strings a look corret in the context of application. We stopped because something completely unexpected happened.

4. Build a community with tech support

Since no one from the founding team had much of prior experience of being an online course instructor, we had to build a lot of functionality mostly by having a dialog with our users. We had a completely open roadmap, were asking for a lot of feedback and were very honest about all limitations. As a first 6 months passed, people started to notice the amount of help and personal attention they were getting from a completely free service.

In rainy october of 2013, roughly 8 months after our launch, I got a message from an informatics teacher, it said the following:

  • School kids in Czech Republic can’t use platform in English
  • You platfrom is already available in Polish
  • Maybe I can help?

That was it — a commitment from a single person to provide completely voluntary help in return for our service. It was a the actual start of our community. After we got Czech localization out and published a story about it, offers of help started pouring in. And by the end of 2013, we had our platform available in over 30 languages.

5. Set up a process for you community

Getting a commitment from volunteers does not mean you can count as on your employees. Almost each person who helped up over this year required a certain amount of help — a crash course on dynamic variables in the text (“don’t translate anything appended with a % sign, don’t add extra spaces”), basic how-to for Pootle and constant follow up.

Right now our community localization process works like this (we try to be as agile as possible):

  • Once a project gets at least 60% of all text translated it get added to production
  • Every 2 weeks we sync all changes in English master file and updates for existing localizations
  • Notify volunteers about changes and ask to check translations on production environment
  • Repeat
Current project progress report from Pootle

With every new language, we publicly say “thank you” for each person who helped us getting it out of the door and are not shy about asking new users for help as well.

This approach is far from perfect because we can’t expect constant commitment and as a result some languages don’t get updates for few months while others are kept in constant 100% sync. Another problem is dialects (we still occasionally get remarks for Kuopio-based finish localization) or disputes over correct use of certain words between users. I’d would love to have a dedicated localization coordinator for each language, but we are not there yet.

However, complaints actually get more people engaged in helping making service better and better and with every user who reports a typo we usually get a new volunteer.


In conclusion, making Eliademy available in multiple languages increased the adoption of your services drastically. According to Google Analytics in the past 30 days Eliademy was visited by people from 179 countries (there are 196 in total). No internationalisation plan involved.

Running a crowd localization project is also by far the easiest way to start working with your community. Engaging users into active contribution gets your service a lifetime evangelists — each person who ever helped us with translation reccomended us to their peers and brought some users in return.

The most important thing you can do as a public service is simply admitting your limitations. Even though we don’t offer professional grade localization, community effort works well enough for most of our users. 80/20 rule always works.

I am certainlty hope our model can be replicated by any software as a service company.


If you feel others need to read this article, please click the ❤ button. You can read more practical tips on startups at Nordic Founders blog, follow on Twitter, on Facebook, or join 450+ members Helsinki Meetup community.