Agile software development is de facto standard for today’s software management (at least for web and mobile software). No matter which methodology you are using, a fast feedback loop and continuous releases are big factors for successful products. However, this faster environment introduces new challenges for software development, such as testing, deploying and translating. While testing and deploying are mostly solved thanks to great libraries (e.g. JUnit) or services (e.g. Codeship), translating is still a painful and manual task for many software companies. My guess is because it involves new stakeholders (translators). Hence, a much more complete view must be applied. The problems of translators are very much different from those developer encounter. In this article I will discuss current technologies for localization (i18n) and how they help or hurt a hassle-free software translation workflow.
Development Tools
Resource Files
Resource files are a way to separate text content from code. Basically all the text content is taken out the code and just referenced by it. As reference a key is usually specified, as in properties or yaml files, or the source text is used, as in string files. Honestly, I am a little bit sensitive on the subject of resource files because it is an extremely complicate topic – sadly, unnecessarily complicated. The problem is that many frameworks and programming languages use a different file format or worse, a dialect of a file format. Some of these file formats are really old and in an ideal world obsolete. However, the biggest problem is that these resource file formats are designed to be used by code, not humans. Translators have a really a hard time to handle such files and must use tools to ensure that nothing breaks. Developers are quick to judge translators when they use Microsoft Word to translate a resource file, but why should a translator know that indentations have meaning in the YAML file format? The best way to handle resource files is to abstract them to the translators and leave them to the developers. With Lingohub (our take to fix localization for Web and Mobile Software) we even went a step further. With special comments developers can add quality checks and/or add context and information for the translators. So we try to leverage the broken concept of resource files and formats to better suite the requirements of translators.
Text Segments Changes
A text segment is an entry in a resource file. As the software changes, the text changes as well. Existing texts are update or removed, new texts are added. Developers normally don’t track these changes, but they are crucial for translators. How should a translator know that a segment needs to be revisited because the source text has changed? Resource files are not suited for keeping track of changes and not losing previous translations. Translation tools on the other hand are especially designed to handle these requirements. Below I explain how a translation memory helps to not lose previous translations and better style consistency.
Localization must be part of your software process.
Integrated Development Environments (IDE)
IDEs are to developers what Computer-assisted translation (CAT) tools are to translators. As you can imagine, they all serve a very special purpose. For developers, things like code completion, refactoring, syntax checks and so forth are important. Translators need context (what comes before/after text, where is the text used), see previous translated texts, and machine translation. Some IDE include an editor for resource files and want to ease texting for developers. In my mind this is the completely wrong thing to do. Developers are neither translators nor writers! They are professional programmers that write application code, they shouldn’t text or translate. Internally, we had the discussion of IDE plugins for Lingohub, we settled on waiting for user demand of this feature. We haven’t had one single user request for such a plugin! I think this is because resource file synchronization shouldn’t be a manual task, it should be done automatically in the background. Either by a script using a REST API or by an integration into the code management tool. IDEs have one purpose, to let developers do their job, nothing else. Or does anyone want an IDE that checks emails, Twitter, Facebook as well?
Code Management like Git(hub)
Code management has been around for ages, but Git(hub) took branching and code sharing to a new level. It is normal that a software project has many branches (10, 20, or more) where each branch reflects an issue (feature or bug fix). Once a branch is done it is then merged into a release branch from which it is then deployed. Branching is something that at first seems to complicate the translation workflow, while in fact it can be used to organize it. Feature branches are fluent, as is the text in it, so it wouldn’t make sense to translate texts from a feature branch. However, when the code goes in the release branch, the translations should already be done. The solution is to introduce a state between – a translation branch. When a developer knows that a text doesn’t change anymore, the code is pushed to this translation branch and the translators are notified that a text needs to be translated. Ideally, the texts are translated when the feature branch is then pushed to production branch. I already wrote an article on this subject on the Lingohub Blog called “Integrating internationalization in a GIT workflow“. The crucial part is that a translation management tool must have a way to integrate into this workflow.
Continuous Deployments
Ten years ago software release cycles happened in months or years turns. The era of desktop applications! Now software is released 2-3 times a week or more! This fact heavily influences the workflow of software translation. Translations are needed fast and much more often, like in an on-demand fashion. However, this also introduces a new burden for translators. They have to react quickly when a job is waiting and instead of having 2-3 big projects, they maybe have 15-20 projects in parallel and work on each just a little bit each week. Keep in mind that projects differ, in tone, style and vocabulary. A translator needs to know how the customers want the text to be translated. Was it “Sign In” in project A and “Log In” in project B, or vice versa? Traditional translator and developer tools are no real help for Continuous Translations.
Translator Tools
Translation Memory (TM)
The big and mighty Translation Memory. Translate it once, use it anytime and anywhere. Sadly, it doesn’t work like that. Of course a well organized TM is a great help for every translator. It speeds up the translation process and helps to have a consistent tone/style. However, it also has it’s limitations. I think developers should have a good understanding why a huge TM (and/or machine translation) cannot replace a translator. Just think of how many web pages are out there. One would assume that every button, transitions, style, … already exists, so why do we need to develop and style web pages over and over again? (similar to translating texts over and over) For me this has a couple of reasons. First, many web pages look similar, but the code still varies in some details. To figure out what can be reused sometimes costs more time than just to create 100% new. Second, every page has it’s tone and style which evolves and changes over time. So if you find a page that is 100% like you want it, either you are the copycat or they are. Third, like the page style and code evolves, so do the technologies themselves. Does anyone still remember Silverlight?
All these reasons apply to translating/texting as well. If you can copy/paste text from somewhere and can use it 100% for your product description, have fun finding your Unique Selling Point (USP). Languages are a living thing. New words come, old words go, some are just randomly generated. It is impossible that a Translation Memory can be used without human interaction (same goes for Machine Translation). Does any developer think that a code generation tool and/or IDE can replace them? I don’t think so. And the same rules apply to a TM.
Elephants never forget. Translation Memory don’t forget translated texts.
Machine Translation
Machine translation is a funny thing. It helps you understand different languages. You understand the meaning of any text if you just use Google Translate. People are tempted to think that it also works vice versa. You can use such a tool to make your text available globally to everyone. But the same problems (and more) apply here as for the translation memory. Honestly, if you translate your mobile app or web app with Google Translate, it means you don’t have respect for other languages (cultures) and probably not for your tool as well (or your customers). As your users deserve a great UI, they deserve fluent and good sounding text as well.
Term Base (TB)
A Term Base allows you give your translator more context. It is best described as a dictionary especially for translators. It describes terms together with their usage (in general or in the project). A good example would be the term LingoChecks. We coined that term for Lingohub, so every translator new to our project has no idea what it is. With a TB it is clear what the term stands for and how to use it.
The Glue (Summary)
Bringing translators and developers together.
Bringing all these technologies and tools together is hard. Believe me, during the last 2 years working on Lingohub I experienced how hard it is. But I think we now know how all this is going to work together. Lingohub already provides great value for companies who are localizing Web and Mobile applications, but I know we can go further. The next step is to bring translators on board and to give them the right tools to do a great job. Helping them to be faster and better in what they love to do. Then are going even further with the integration of localization into the software process. I strongly believe that in 10 years, there isn’t a question of localization or not, it is a question of how many languages you are localizing for.
With that in mind, Go Global, Be Local! 
Lingohub – Better software localization in less time
LingoIO – Register for early access!
The post Agile software development meets lean translation managment appeared first on He. M. Ju..
