Software localization should be interpreted as the adaptation of a software product to the linguistic, cultural and technical necessities of a certain target audience. In other words, it does not only imply translation of text, but also adjustment of the functionalities of a software application.


As a matter of fact, software localization is bound to certain rules and technical requirements that intensify the localization process. Length restriction is probably the best known rule that needs to be followed when translating software strings. The translations of button names, screen names, dialog names etc. should fit in their corresponding boxes. This sounds self-evident, but it can be really problematic. We all know how the French language is embellished with a lot of “crème fraîche”, right? Or how Spanish speakers chock up their sentences with redundant words without actually saying anything meaningful?

Another example of a software localization rule is the correct adaptation of hotkeys. Each hotkey has to be unique in the target language dialogue or menu and must reflect a clear link with the task it is supposed to perform.

The above mentioned examples are quite basic and relatively easy to handle, but other unexpected obstacles (or even unpleasant surprises) might pop up during a software localization project. What is, for instance, the best way to deal with Arabic (or any other right-to-left language)? How should hard-coded data formats be processed if your localization environment doesn’t seem to support those?

When several of these factors, both linguistic and technical, accumulate during a software localization project, it might turn into a complex and laborious job that requires a sharp focus and a good night’s rest for everybody working on it. This does not only apply to translators, but also (and especially) to software engineers, project managers and QA specialists.


At Yamagata Europe, we handle software localization projects on a regular basis. These projects do not only include actual translation orders, but also trainings and troubleshooting. The practical experiences I’ve gained since I joined the company in January 2013 have taught me that the appropriate use of a software localization tool is essential in order to work things out efficiently. The main tools that are used at Yamagata Europe are SDL Passolo and Alchemy Catalyst. These localization platforms offer a wide variety of applications that contribute to smoother localization at the level of software engineering, project preparation, translation and post-processing. Note that the aim of this blog post is not to give a detailed product overview of these localization environments (it would be more appropriate to write a book in that case), but rather to give a few examples of interesting features.

TM integration

A clear example of such a feature is the integration of translation memory systems, intended for leverage at the stage of (pre-)translation. Passolo is compatible with SDL Trados Workbench and Studio TMs, Catalyst supports TM files in for example TTK, TMX and TXT format. TM leverage statistics can be analyzed when starting up a project and new TMs can be created by aligning earlier translated materials.


It goes without saying that terminology management is of extreme importance in software localization. You don’t expect every occurrence of a certain button name to be translated differently, right? For that reason, both Passolo and Catalyst also allow to create or to upload terminology glossaries. Passolo has an internal glossary file type, i.e. *.glo. Catalyst supports numerous glossary formats such as TXT, TBX, TMX and SDL MultiTerm databases.


Their biggest asset is probably the WYSIWYG (What You See Is What You Get) environment. This feature enables users to visualize the translations in the software application while creating and/or editing them. That way, it is easier to avoid all kinds of technical issues that might arise during the post-processing stage. Nevertheless, this does not guarantee that all possible mistakes are detected and corrected while translating. Therefore, Passolo and Catalyst offer several QA functionalities. Issues that are not spotted during translation can be easily fixed after translation by performing a QA check. QA options, both general and software-specific, can be (de)activated in accordance with the needs of the QA specialist.

It seems appropriate to conclude that software localization implies particularities that clearly distinguish it from other disciplines in the localization industry. All stages of the localization process – from software engineering to QA check – are characterized by all sorts of technical requirements that demand some knowledge and practical experience in order to get things right. This makes software localization intensive and complex, but also very challenging.