Our Localization Odyssey
“Harry Potter and the Stone of the Wise Men” is one of the most best-selling books of all time…
…something in the title seems odd, isn’t it? 🤔
That’s because this is the direct translation from the dutch title of the book: “Harry Potter en de Steen der Wijzen”.
The original title of the book (Harry Potter and the Philosopher’s Stone) and the book itself is written in English but in order to reach a broader audience and make it more attractive to people of different countries it had to be translated to other languages while taking into consideration the cultural norms of each country and adjust the text whenever it made sense to do so.
A similar concept takes place when it comes to apps:
App localization is the process of adapting your application so it suits to different languages and cultures.
Let’s keep in mind that adapting the app to the preferred country/market entails adjustments not only in translations but in other areas too, such as date formats, unit or currency conversion, technological requirements etc. and those are also part of the localization process.
Localizing a multi-platform(Android, iOS, Web) product and keeping every role that is involved in that workflow as happy as possible can be quite a task. Fortunately, there are already many localization and translation management tools out there that could assist us in that process.
Meanwhile, there is also plenty of willingness in Luscii for trying new processes and technologies out. This openness is something I enjoy in this company since I realized it could be really beneficial both for the team and our product and a catalyst for overcoming challenges.
The beginning
I joined Luscii as an android developer more than 2 years ago. Back then the team was already using POEditor as a localization management platform and the workflow was as follows:
- Developers were pushing the translation keys (unique identifiers that act as placeholders and will be replaced by the corresponding translation value based on the chosen language) in POEditor.
- Voice of Product (the role we have at Luscii with copy-writing responsibilities) was setting the English texts and adding translations for Dutch (yes, our Voice of Product is Dutch, so it makes sense 😜).
- Developers had again to pull the translated texts into their respective projects (Android, iOS, Web, API)
It’s worth mentioning that at this stage, Luscii as a company was growing fast and needed many iterations of the product, focusing on flexibility instead of maintainability. Therefore “Iteration even over Perfection” is one of our strategies at Luscii.
And here came the first iteration 🥁:
Iteration #1
There was too much hassle for the developers and the ad-hoc way of asking and waiting for translations was causing too many unnecessary interruptions to the team.
First, we agreed that only developers will be responsible to keep POEditor updated from that point on. The VoP (Voice of Product) will have to add the English texts along with their translations directly in the tickets (or the designs) of the features that need to be developed. Furthermore, we added a web-hook in our CI flow so the keys and the translations in POEditor will get updated with the latest values every time developers finish a feature.
Consequently, the work for developers was simplified, since all they had to do was to add the translations directly in their code.
We followed that workflow on our Android and iOS projects for almost a year and there was a plan to integrate it to our Web and API projects too… but then…
Even though that flow made developers’ lives easier, new tensions arose from other roles in the team. There were still cases (mainly on smaller tasks and bug fixes) where developers were missing translations and this led again to an ad-hoc way of asking for texts. That was a problem, especially for our VoP, because he was losing focus very often. Requests from developers of all the platforms were coming in and it was not always easy to know the context or keep a consistent voice between them.
Moreover, Luscii started becoming bigger and getting expanded in other countries. We could see that our apps sooner or later will need to support even more languages and now it was a good time for another iteration.
Iteration #2
Our use-cases:
As a Developer, I want to have available all the translations needed for the task I am working on, so I can complete it.
As a Voice of Product, I want to have a good overview of the texts used in all the platforms (Android, iOS, Web, API) accompanied with screenshots, all in one place, so I can have a better context and keep a consistent voice when entering the English and Dutch texts.
As a Translator, I want to have the keys and the English translations in one place, so I can enter the texts in my language.
As a Designer, I want to test my designs on other supported languages, to be able to check that they still look awesome.
After some research we ended up with Lokalise, as our new localization and translation management platform, since we imagined that it would fit the best in covering the use-cases mentioned above.
The key features that made us choose this platform among others were:
- The Figma plugin, since we are using Figma for our designs. Through this plugin our designer can push directly the translation keys for the texts along with a screenshot of where those texts are used.
- A clean overview and an easy way for our VoP and Translators to add new translations.
- CLI (command-line interface) tool which developers can easily use to update the translations in their projects.
- A good notification system so the respective roles will be alerted when needed.
- The possibility to use the same keys for all the platforms and a “Duplicate finder” feature where we can merge same translations.
We wanted to start as clean as possible so before we upload to Lokalise the translations we had so far, we deleted any keys that were not used anymore and removed all the duplicate translations of each project.
The next step was to define a universal naming convention for the keys so the same ones could be used from all the platforms and would be easier for our designer to generate new ones while keeping demanding developers satisfied at the same time.
Finally, we uploaded the translations from each platform to Lokalise, merged any duplicates that needed to be merged and now we were ready to start using our translations workflow 🎉.
Two things worth noticing in the chart above are:
- the translations workflow starts with our Designer during the early design-stage of the feature.
- Lokalise is the single source of truth for keys and translations.
Sprechen Sie Deutsch 🇩🇪?
As Luscii is going global, two months after setting up our workflow, we got a request to add the German language. Good timing!
When it comes to translations there were mainly two steps needed:
- Add German in the project language list in Lokalise platform and make a request to German Translators.
- The platforms have to enable the language and then use the CLI to pull the texts of the new language in their respective projects.
Of course, just adding the new translations is not enough when integrating a new language in such a big multi-platform project. There are many other tasks like updating the texts in the app stores and in our email templates, updating our Web app so it shows the new language in the toggles, etc.
However, the part of adding the translations of the new language was very easy and straight-forward for all the platforms.
Should we expect more iterations?
Definitely. There is still room for improvement. In fact we already added a small one:
At first we were very strict with whom is touching the translations in Lokalise. Designer was the only one allowed to add keys so developers had to ask him each time. We wanted to avoid letting every developer adding keys/translations ad-hoc, which might mess other platforms or the consistent voice over the whole product.
However, this caused a bottleneck. What’s more, there were even cases that we wanted texts but there was no need for designs at all. The solution was to make the process a bit more flexible, thus developers are now also allowed to add new keys and should inform the VoP when needed.
That’s our localization Odyssey till now; we are aware that is still not over; nevertheless, so far, we have defeated many of the monsters we have encountered, we have the flexibility to adjust in case we face new ones and that gives us the chance to enjoy the journey ⛵️.
