Keeping Localization Agile at Gameeleon

 TL; DR Do not bang your head on the wall trying to send and retrieve complex contents for translation. Your localization provider has you covered when it comes to making localization Agile!

The translation industry and the translators have come a long way since the times of copy monks and ancient civilizations. It is one of the oldest jobs in the world but even though languages still work the same way, it doesn’t mean translation has always worked the same. However, there’s still a weird image that sticks around:
A translator speaks multiple languages, has a luck-keeping paper dictionary and reluctantly uses MS Word because writing becomes impractical. That couldn’t be more wrong. Translation and localization today gather great linguistic and technical capacities and work hand-in-hand with your Agile workflows.

Why translation made itself Agile?

Let’s face it: having external service providers intervene in the development flow of your apps and games, in an early or late stage, is complicated. And we don’t mention the fact developers mainly need to focus on the product and localization remains a vague subject to some of them.

In the world of live updates of apps, games and software it is pretty annoying to have to:

• Extract the texts to a human readable format (who said Excel?)
• Get a quote from your provider
• Send all contents for translation into many languages
• Wait
• Receive the translated contents
• Check the translated contents for missing tags
• Reintegrate the texts into the right data format

Not only is the process long, it also involves a lot of checks a developer should not have to take care of.

For this reason translation service providers use a set of tools and practices that help better integrate the translation process into your workflows in an automated fashion and trim this list from A LOT of manual actions.

How does it do that?

The whole point of agile localization is to bridge the gap between the work of a translator and the work of a developer, which are miles away from each other, in the most transparent and automated manner.

No need to prepare every file

Translating requires UI ergonomics and focus, just like coding, in order to output the best quality possible. In order to work properly, a translator simply cannot look through a JSON file and translate it in some text editor (hence the text extraction in readable format like Excel). This is a tedious step that modern Translation Management Systems, the IDE of the translators, easily do today. It allows the translators to enter “zen mode”, without all the distractions of the original format while still preserving the interactive use of online dictionaries, spell checking, tags and variables checking, previous translations references, glossary, etc. The System then outputs a translated version of the original text data in its original format. This renders the text extraction/reintegration step from/to its data format useless. And that’s already a headache a good localization process spares you.

Automated communication

One of the major keys of integrating localization in workflows are the connectors that link Translation Management Systems and your workflows. There are many types of connectors and ways to automatize them.

Their primary purpose is to securely pull files in the source language and push their translated versions back at specific intervals or on specific events. Most connectors are used to connect Translation Management Systems with file clouds like google Drive or DropBox, but they become even more interesting when we know they can do the same on a Git branch. You could imagine a connector that would work on a “loc” branch that you could merge regularly into your next release branch. It also means it is much easier to backtrack localization issues since that’s what Git is made for.

No file preparation and working directly in your repository. There you start to see why we call localization an Agile process

Versioning

Maybe one of your biggest concerns when it comes to localization: How to update (add/modify/delete) keys from the localization files and have that reflected in the target language files? Deleting a key is easy to do in every language; just remove them. Adding is also easy; just do it and leave translated versions blank. The translator will see it and take action. But what about modifying a string? How to catch the attention of the translator so they can modify the translations as well? We could:

• delete all the target version and get everything re-translated. No: think about costs if you only modified an adverb or a name in a 50 words string!
• add a “__modified__” annotation to the source content. No: you’d be polluting values with metadata that would be counted as words.
• add a “modified” annotation as comment. Better: that would work, but that requires careful consistency for all content writers because the Translation Management System will detect annotations as long as they are well formed.
• send a git diff. Fair: the translator would see what has been modified without having to rely on annotations. But… You’re breaking the automated process with sending a diff manually. Also how can you quantify what has been modified to keep track of your budget?

Let’s stop here because here’s the best solution: Do nothing. 🙂

It may sound weird for hard working individuals, but everything is being taken care of on the Translation Management System. As long as you’re working with key/value pairs, you need to be aware that the system keeps track of all translated key/value pairs internally and is perfectly able to detect keys that have never been translated and keys that have been translated, but whose content has changed since the last localization iteration. Those of you familiar with Git will think it’s the same, but not exactly: Git acts at a line of code level by making a diff. The Translation Management System first checks the keys against its translation database (called a translation memory) and then diffs the previous with the current string.

Already translated content is automatically retrieved in all languages, deleted content is simply ignored and modified content can be properly quantified as a “percentage of modification”. All this safely without adding any workload. How nice is that?

Conclusion

There are a lot of things a good localization provider can spare you to make your job easier when it comes to opening your creations to new markets around the world. Obviously this kind of setup are recommended to continuous development flows, but can also be perfectly fitting for recurring translation requests from e.g. Marketing teams using Google Drive.

Therefore, do not fear localization! It knows how to make itself easy and seamless as long as you work with the right provider. Don’t hesitate to ask a Gameeleon Project Manager to help you setup this Agile automation in details!