My name is Andrey. I’m a product manager at inDrive, and I work on passenger flow development — the company’s main service. In this article, I’ll be talking about how we drew up a process of localization for the company, with a little pain and a few errors along the way.

First, I’ll describe how we evolved in terms of choosing localization tools. Then I’ll share some problems that we faced when translating the app into Arabic. Finally, I’ll show you the new localization procedure at inDrive, and how we successfully applied it in the case of Kazakh in June of this year.

Start. Excel

A few raw figures: around 4 million trips a day are made via inDrive. We now work in more than 700 cities in 47 countries. I’d like to reiterate that: 47 countries. At least half of them speak different languages, and the app needs to be translated into these languages.

At the start of our localization journey we used Excel. This gave us a complete picture of our structuralized system for setting deadlines, translations and sources. The source is the original language, from which translations into other languages are drawn up. In our app, the source language is English.

How it looked at the start

Excel was only useful in the initial period. We liked it for its simplicity and clarity: we were able to explain how to use the tool to newbies very easily. Over time, though, the number of languages we were working with increased, and the product itself grew in terms of lines and screens. As a result, we ended up with 68 tabs in a table with thousands of rows and columns. We knew that if newbies were shown the document, we might never see them again.

It became clear that we had to look for another solution.

Development. Wrike, Crowdin and Jira

The solutions were Wrike, Crowdin and Jira. We use Wrike to communicate with other departments that have no connection with the product or technical divisions: business, marketing and so on. Crowdin is a translation tool that stores all the lines used, and the translations for them. Jira is the home of all our tasks: we exist there cosily together with the QA technicians and developers.

I’ll show you what our Crowdin looks like. On the left are the lines of a translation for a particular project. There can be various projects: it all depends on how you integrate the service into your product. Crowdin also allows you to share the localization among platforms in a convenient way: backend, Android, iOS.

In the upper right-hand section, we see the source, and below it is translations with various alternatives, which need to be approved. The tool is customizable — you can use the settings that suit you.

After implementing the tools, we moved on to other areas of our work. There were some drawbacks to the way the processes were set up, though. Let’s say that the business had announced the launch of a locale and country. We had to find out which currency was used there, which features should be launched, which payment methods included, and how to communicate with the user. A lot of time went into clarifying the details and finalizing the requirements.

Besides the passenger structure, there are other teams too: drivers, payments, messenger, and so on. They all work on a quarterly basis and plan tasks for that period of time. Accordingly, the teams add translation tasks to their schedule in a sporadic manner. A typical scenario might be: we translated the passenger flow in October, but the driver team didn’t do it until November. As a result, the user got the localization in December. This was the problem of not synchronizing translations and checks.

In addition, there was a kind of ping-pong game going on between the localizers and the product teams: because we didn’t have enough translations, there were some gray areas and inaccuracies. We had to spend time not on the checking itself, but on looking for incomplete lines and adding or changing a translation.

Change of process. The case of Arabic

By its very nature, the Arabic language is difficult to learn, because you need to change the way you perceive information. It’s akin to a right-hander suddenly having to become left-handed and change their long-established patterns of behavior. That’s how it is with Arabic: you need to read from right to left, in addition to swiping and doing all the other movements. This is a headache for both developers and QA technicians.

A good example of what swiping looks like in the Arabic locale

Two months were spent checking and adding the Arabic locale to inDrive. The technicians were racking their brains, the testers were maxed out — it was a real head-scratcher. When someone does the same thing for two whole months, they lose motivation and work less effectively on their subsequent projects.

Below are all the screens showing our bugs on the Arabic locale. There are vast numbers of them, thousands, perhaps even millions. The QA technicians called this whole process “Alice through the Looking Glass”, and this spilled over into internal memes, some of which took root at the company.

There wasn’t room for everything, of course

We realized that there were some problems with our approach to localization:

• Lack of clear requirements.
• The fact that no one department, in particular, was responsible. If there’s no department responsible for localization, then there’s no one person who’s responsible.
• Incorrect translation. We communicated very little with speakers of the language, and spoke to specialists, thinking that they would know everything. Their knowledge was of the academic kind, though, and wasn’t applicable to ordinary communication with users.
• Missing parts in the translations. Our app is very big, and, naturally, human error plays a part. Sometimes translations, or parts of them, are missing. Meaning, someone places a huge volume of text in front of you and says: “Translate all this”, and mistakes are made.
• Problems with the app’s layout. When you translate a word, let’s say “Apply”, into Thai or Hindi, you may get more characters than there are in the source word. And, of course, the text doesn’t fit into the app.

The solution. The UX writer makes its entrance

To remedy the situation, we have formed a product localization department. I’d like to talk on a separate note about the position of UX writer, which I’ll describe below, within it.

We prepared a single, common template for business requirements. If someone comes up to us and says: “Let’s launch in Kenya”, we show them the template and say: “Here, fill this out”. Once it’s filled in, we decide whether to do the localization or not, in what timescales, and in what form it should be added to the schedule. We also started checking translations with native speakers of the language. This is a very important factor, because when you’re talking about 47 countries, it may be that we don’t know all the cultural features and ethical norms of these countries.

We also created some funnels for the Crowdin app. If we have a huge locale, a vast layer of work, then we need to break everything down. We formed primary and secondary funnels.

We also fine-tuned Crowdin and gave the translation added context. If someone translates the word “apply”, for example, we tell them which screen it appears on, and the number of characters we recommend for the translation. The translator immediately knows what screen it will appear on, and will try to choose a synonym or a word that fits the number of characters.

We now come to the UX Writer. Her name is Liza Vorobyeva.

I was really pleased when she came to join us. Below is an example of what her work is all about. Liza simply looked at this screen and said: “Terrible!” On the old screen, additional actions were required on the part of the user, and some of the text was unclear and difficult to understand.

She got rid of the checkbox at the top, as an unnecessary action, and added the message: “By selecting ‘Turn on camera’, you agree with our public offer and confidentiality policy”, and started chatting with the user. They talked about what really matters to the user — “The photo will not be published anywhere”.

By changing the text and shortening the user flow by one step, we increased conversion by 7%. This is an excellent example of what the work of a UX writer involves. In addition to revising texts, Liza produced three very important documents:

1. Tone of Voice — the service voice that you use when communicating with the user. I’ll give you an example. You need a friendly tone of voice when communicating on social networks. In technical support, however, you have to speak in an official-sounding way, but with a note of concern and support.
2. Editorial policy. This policy helped us draw up the wording for the texts. I.e. where to place periods in headings, and where not to. Those are straightforward examples.
3. Glossary. When conversing, you can refer to the same feature using a range of different names. In an app, though, there must always be only one name. “Balance” must be “balance” throughout the app. Not “wallet”, or other similar words.

I’ll give you an example of the inDrive launch, which took place this year. We took the English text that was in Crowdin, rephrased it and launched it in the country. What outcome did we get from this? We expanded our target audience: our product started to be used by people who hadn’t ever used it before. And, most importantly of all, we made the product ethical.

I’ll tell you about the time we screwed up. If you look at the example below, you can see the buttons “Reject” and “Accept”. In Azerbaijani, though, instead of saying “Reject”, the text says “Beat it”. This just goes to show that all texts need to be checked with a native speaker of the language.

The only department that accepts translation jobs from us is the product localization department. It determines the requirements and volume of the translation, and also the teams that are needed in order for the product to be launched in one country or another.

The translations are created, and then there is a review and a check by native speakers of the language. If everything’s okay, we merge them in branches, test them and deliver them to the user, i.e. to production.

Schematically, the process looks like this

To sum up. The case of localizing the app into Kazakh

After the transition to the new process, the first page we had to localize was Kazakhstan. An amazing thing happened: instead of taking eight weeks, the localization took us just four weeks. We had prepared some mock-ups beforehand, so that everyone could see and understand the flow. We added translations to the mock-ups, to provide greater context for the translators and native speakers of the language, and they understood what we wanted to translate and what we wanted to get from them.

The mock-ups were localized into Kazakh

Naturally, there were some bugs after the production step. In the past, we would react badly to them: “Damn, another bug”. But now we view them as something to be taken for granted. We introduced the practice of having a two-week trial period, when we know there’ll be bugs that need fixing as quickly as possible.

The Kazakh media have started writing about us. I always try to present the results of the work, so that a person from, let’s say, Atyrau or Paphos sees that their work is visible and has made it as far as the user, that it’s valued. This gives each member of the team extra motivation. They see that their product, which they have created and developed, is being used by ordinary people on the other side of the world.

In Kazakhstan we’ve also started the trial period for the first time. That is, the task is not completed once the product makes it to production. You gather feedback and carry out additional checks with specialists — i.e. native speakers of the language. We also realized that unique mock-ups are very useful for Crowdin.

I’d like to end by summing up and giving some advice on localization:

1. If your tools aren’t helping, change them. If you’re used to them, carry out an assessment of them anyway, and review them. They should always work for you, not the other way around. Otherwise, they could grow into a real burden, which won’t make much sense either to new employees of the company, whose eyes are still sharp or to those who are currently working with them and are plowing the same old furrow.
2. Detect pain through communication. Don’t only talk to people who are always in the process of further development. Communicate with the business department, and with the other marketing departments. They might express their pain, and you will be able to find significant solutions to insignificant problems.
3. Don’t be afraid to offer these solutions, because your thoughts may be a continuation of what the other person is thinking. Eventually, you’ll arrive at the truth that will lead to an improvement in the process or product quality.
4. Seek the help of specialists. None of us is perfect. Of course, we’re good at one or another specialist subject, in this or that area. But there is always someone who knows more about it than we do. And, naturally, we need to approach native speakers of the language.

Finally, I’d like to acknowledge the contribution made by the QA technicians, who are passionate about product quality and thank Tolya Vladimirov, Katya Okhlopkova and Tanya Struchkova for helping me write this article.