At LOVOO, we work using agile methods and have small iteration cycles with continuous deployment. This method of software development is fast and has regular product updates with lots of tiny changes – a real challenge for the localization process. Software development is so fast that it does not make much sense to develop first and localize once we have the final product. By the time localization would be done the traditional way, emailing language service providers the content, waiting for translation and re-implementing everything, the product would most likely be overhauled and some, if not all, translation material outdated.
So, how do we do translation @ LOVOO?
Tools and automation help us a lot in building an agile translation process that suits our needs.
We want fast translation, seamless implementation and low-effort automation – and, of course, high quality and low costs. In the following paragraphs, I want to introduce our process by first detailing problems and then explaining our solutions for them.
Fast and regular updates and the question of content transport
Imagine a translation job where you extract the content for translation from the original files, format the material in a document that is easy to process with translation tools and finally send it on its way via email. Once the content gets back, you have to copy and paste the translations in their locale-specific origins and implement everything back into the code. A very laborious and tiresome process, prone to errors and not scalable for any greater number of languages. It is also very frustrating for all parties involved and does not have the flexibility to accommodate source text changes. To ensure we get the required level of flexibility, we need both a non-linear content localization strategy and automation. In the ideal case, we have a single source of master texts that remains as up-to-date as possible, which is something you already have in software localization. This is the code you are developing which usually only contains strings in a language understood by most of the developers (like English or, in our case, German).
Now, you just need a way to connect translators to the code base, ensure that they can focus on translation and not get distracted by the code or change the wrong things in the wrong files by accident.
We solved this problem by connecting an online translation platform via an REST API to our CI/CD system. So every time a code change involving the source material is made, the (updated) master strings are automatically uploaded to the translation platform. Then the completed translations for our current 14 target languages are downloaded and integrated directly into our code as resource files. This is done by means of pull requests which are reviewed by developers and localization experts, and then merged into the code base. We have fixed intervals for collecting new translations for previous material several times a day. We only check for a complete translation in our fallback language – English – so that we don’t slow down our release cycles before releasing a new version. All other languages are updated constantly and don’t block releases. This means that new versions of LOVOO will always be completely localized in German and English, but may only be partially localized in other languages. The untranslated strings fall back to English by default. Over the course of the following releases (usually one immediately following) these languages are then finalized as well.
Online translation platforms you might want to look at are ‘PhraseApp’, ‘Transifex’, ‘GetLocalization’, ‘Lingohub’, ‘Crowdin’ and ‘Smartling’. There is also a wide variety of other solutions on the market.
In addition to providing human translators with an automatable interface, translation tools provide tidy dashboards which allow you to see the translation progress in each language. (Having a dashboard is really nice, but after a certain number of languages you ignore it most of the time and start using APIs, if available. The only language that usually matters is the fallback (usually English unless it is already your master – that is development – language). The others get updated quickly as you release new versions and updates) They also come with a translation memory system that lets you reuse content you already translated before and thus save time and money. Furthermore, they display how much work each translator has done – making invoicing easy and straightforward. Those platforms can also be used for all kinds of different content: product content, marketing content and help materials can all be translated with leveraged memories that help to ensure consistency throughout the material.
Nonetheless, working with these platforms presents challenges that we had to overcome: when working with freelancers or translation agencies, it is important to have certain SLAs in place to ensure that even low volumes are translated with acceptable turnaround times. Additionally, you should negotiate a continuous translation agreement so that each job is triggered automatically – saving time on Purchase Orders or negotiations and ensuring the same translator/voice is doing most of the content. This means that you also need to control what content reaches the platform because costs quickly accumulate when everything gets translated quickly into so many languages. At LOVOO, we only upload the master file to our translation platform once the code has been merged from the feature branch into the development or master branch, thus ensuring that not too many things are changed afterwards, requiring another localization loop. Another challenge is to provide the right amount of context and to make yourself available for questions and enquiries at all times. A drawback of such platforms is that they are usually not quite as translator-friendly (spellcheck, machine translation, concordance search, match display etc.) as industry standard tools for document translation (SDL’s Trados or Kilgray’s MemoQ). Nevertheless, the development teams of such platforms are usually dedicated and improve their products on an ongoing basis.
Language QA and limited testing time
The second problem caused by speed is the limited time we have for language testing. The content is translated so fast that there cannot be any in-app reviews, since it might be the case that new or updated texts are translated and released in about 48 hrs. This kind of super quick language testing is not feasible because we neither have the resources nor speak the languages in-house, but the timeframe AND our way of working do not permit us to spend time on Language Quality Assurance. It is preferable to iterate quickly and fix bugs as we go along instead of setting aside time in advance for perfecting things and never getting anything done. So how do we take care of quality? We have to live with the risk of exposing content that contains slipups or typos. However, we also make sure that we provide a point of contact for fast troubleshooting (i.e. a localization manager :-D) for customers (via support) and coworkers alike.
Quality management and transparency
All in all, we have a three-tier quality management process that consists of (1) a textual review, (2) a crowd test on a varied platform model and (3) independent language reviews of the product in context. With the exception of the textual review, all testing is done after the product release and not before, with the most important thing being that you remain flexible and have a fast process (see problem 1) to include direct user feedback and to respond to that, if necessary.
To aid the improvement of transparency and ensure that we don’t release before the fallback language is 100% translated, we have to communicate the translation status of the fallback language to the various teams very transparently, while avoiding constant questioning when the translations are complete. This is achieved by putting monitors in the team rooms displaying the translation status for all platforms and languages with a color scale – green means that it can be released right away (particularly for the fallback language), while red means that our English fallback is still being worked on. All other languages are displayed in yellow when unfinished and disappear completely when done, this guarantees a quick overview and ensures that the teams can work on their releases independently.
All in all, these solutions help us to ensure that translation does not become a bottleneck for product development and that we are able to release quickly on all markets. I hope this short overview helps you build a setup that works for your product and way of working.