Since our first international launch in 2012, we’d understood the importance of localising a product to the market. That is, it wasn’t enough to simply collect high-quality restaurant data and present it in a one-size-fits-all way–it needed to cater to local trends and behaviour in each market, and more importantly, be easily understandable and relatable for people using it there.

In November 2013, things got very interesting and a whole lot more challenging. We were launching Zomato in Turkey, Brazil, and Indonesia–countries where English wasn’t the first language–which meant we’d have to translate our app and website as part of our localisation efforts.

At the time, we didn’t really know where to begin, or how to go about translating thousands of lines of copy across our product. So for these three big launches (and then until the summer of 2014), we took the manual approach:

Once a new page or a feature was built, the engineer working on it would export a CSV file with all the English strings (a string is the text displayed on the app/website) and send it to our localisation team. Our local translators would input the translated text and send the CSV back for the engineering team to upload manually. Rinse, repeat.

Things changed in the summer of 2014, when a small team (led by our rockstar intern Shashank) got together to build our own translation tool that would simplify this process, and save a whole lot of time for our translators and engineers alike. Given all the different flavours (languages) the tool would serve up, we chose to dub it ‘Food Court’.

Whenever new strings were added to the codebase, they would automatically appear in Food Court as ‘Untranslated’, and translators would receive an alert. All they had to do then was open up Food Court, and input the translation directly into the tool. Once they were done, engineers could easily export and deploy the langfiles directly with a couple of clicks.

Food Court now supports file formats for the various platforms Zomato is available on– .json, .strings, .xml, .ini and .resjson.

Three years down the translations road, we decided to look back and share some of the key lessons we’ve learned. We also hope these will be helpful for anyone planning to build their own tools (or even opting to use one of the many third-party solutions now available out there).

Lesson #1: Sentence construction doesn’t always scale across languages

When we launched social features on Zomato, our strings and notifications looked similar to what Facebook had a few years ago. For instance: <Username> just added <5 photos> of <restaurant name> to <her/his> Food Journey.

We thought our translators would just translate “just added”, “photos” “of”, “to”, and “Food Journey”, and we’d just have to concatenate them. Easy enough, right? Nope. Not quite.

While it reads fine in English, in Turkish, for instance, that sentence would be structured as: <5 photos> of <restaurant name> just added by <Username> to <her/his> Food Journey.

Every language comes with its own rules and challenges, which has taught us to think about how the product will work across languages once they’re translated. Oh, and we simplified those strings, too 🙂

Lesson #2: Avoid one-size-fits-all copy

It’s quite tempting to reuse and repurpose one string in multiple places, so you don’t need to create new key-string pairs. For instance, in early versions of our Zomato for Business app, strings for the “Active” and “Archived” tabs were being used uniformly across the Promos, Events, and Special Menus sections.

While it’s the same word in English, this is what happens in Portuguese, Spanish, and Italian:

This meant that our translators were forced to use just one of these translations, knowing it would be grammatically incorrect in places. That’s when we decided to fix this by creating individual key-string pairs for each of the cases.

Lesson #3: Learn how to count again

In our early days, writing strings that included numbers was easy–the number was a variable, to which we concatenated strings for the singular and plural words. For example, “1 comment”, and “4 comments”, which worked fine for Turkish, Indonesian, and Portuguese as well.

Things changed when we expanded to Poland, the Czech republic, and Slovakia, where our local teams told us we couldn’t simply replace “comments” with the plural “komentáře”, because the translation changes depending on the number it’s referring to.

The quick and easy fix was to flip the string around in these languages so “4 comments” would become “Komentáře: 4”. But that was hardly a natural way to read it, so the only acceptable solution meant handling each of these cases individually:

• Singular
• Plurals from 2–4
• Plurals for 5+

This involved a little bit of tinkering on the engineering front, and we had to make sure we covered all of the instances (in fact, I still explain this to our engineers so often that I have a canned response saved in my drafts to send when needed!).

Lesson #4: If you design only for English, things will break in other languages

Your product copy is in English. Great, a majority of your users speak it anyway. But what happens when you decide to launch in countries where it isn’t the dominant languages? How do you know your copy will work for that market?

Let’s look at our old Collections tiles, for example. It consisted of an image, a label with the name of the Collection, and the number of restaurants in it. And here’s how the “Trending this Week” tile looked in English and Polish:

There are clearly a couple of usability issues here:

1) You can’t read the entire collection name.
English is a relatively compact language, but others aren’t quite so:
“St. Patrick’s Day” becomes “Dzień Świętego Patryka” in Polish,
“Roma Film Festival” is “Festival del Cinema di Roma” in Italian.

2) You can’t see the number of outlets.
Remember that issue with counting things we explained earlier (and tried to solve by using “Restauracje: 4” for “4 outlets”)? In this case, that solution created a new problem–two text labels were getting truncated and one couldn’t see information that really mattered.

Over time, our collections have gone through a number of design iterations, but one of the primary requirements is that they have to work in all the languages we support. Here’s the same tile today:

This was a key lesson for our design team, which now does mockups with the longest possible translations, instead of using English or Lorem Ipsum.

One evening in Lisbon, I was catching up with a few Zomato users over dinner. One of them–who uses the app almost every day–asked, “So tell me, why can’t we suggest improvements on the content of the restaurant pages?”.

I was stumped.

How did this power user not notice the “Report error” button we have on every restaurant page? That’s when I realised I had translated “Report error” quite literally, and it didn’t read as naturally as it could have. Lesson learned, I quickly reworded it to make it more obvious and natural.

This is why I want to iterate that translations isn’t a one-off activity. It’s an ongoing investment, because you’ll keep adding features, changing copy, and revisiting old translations to ensure they’re still locally and culturally relevant.

Yes, it’s an awful lot to do, especially when most of our users may speak English. We may not hire a company to do this, but there are costs involved–launching a new language internally could take over three weeks of full-time translation work. That’s a lot of time for one person, especially when we’re launching a new market and need everyone to be out on the field. There’s a lot of work post-launch as well–improvements and tweaks as we learn about what makes people tick, adjusting our accent, and not to mention at least 4 hours of translation tasks a week.