Translation Services

Monday, September 23, 2013

One of the major headaches for software development companies is Software Localization and the release of a SIM ship version of their software to market. In an ideal world the localized or translated versions of the software should be released to market on the same date as the original version which is usually English, a concept known as SIM ship software. With this in mind it is important to run the localization process in parallel with the initial development process. If we delay the localization cycle until the end of the development process this will incur extra costs and also delay the SIM ship version of the software due source code changes caused by the localization process. To overcome these difficulties there are a number of preemptive localization steps that we can take in parallel with software development.

1. Pseudo Localization of Software

Our first step is to pseudo-translate the software pilot languages. If we have many languages to localize (translate) we choose a small cross section of languages to represent all the target languages to be translated.
During pseudo localization the target text is pseudo translated as follows:
- The translatable text is isolated
- The translatable text is pseudo translated
- The pseudo translated text it is dumped back into the software code
The pseudo translated text represents the target language and can uncover various functionality and UI bugs during initial development that can be fixed at this stage as opposed to during the software localization/translation phase when it may be too difficult or expensive to fix! Some of the typical bugs uncovered during the pseudo translation phase include:
- Rendering of the target text on the UI. The target text is more often than not longer than the source text especially in the case of English making the text appear cut or overlap other UI components. For instance in the case of English, the other main European FIGS (French, Italian, German and Spanish) languages can be up to 30% longer than English. This allows us to set character limits for menus and dialogues before translation begins.
- Glyphs such as the accent or acute not found in the source language may be cut off in the target language.
- Languages such as Arabic that read right to left may cause serious input issues
- The original character set may not accommodate all the source characters
- Identifying hard coded text where the localizable text is embedded in the code
Catching these bugs during pseudo translation of the software ensures a seamless translation phase! The pseudo translation generally identifies all the most common problems of the target versions. Its best to run the pseudo translation when the original version is fully functional.

2. Pilot Language for Software Localization

Now we begin the software localization process in earnest by choosing a pilot language which is a language version of the software translated before the other languages. This language will define the localization process and weed out the majority of the localization bugs.

3. Translation Memory Input during software localization.

The actual software localization process is similar to the pseudo translation process in that the translatable text is isolated, translated and dumped back into the software, however, there is an extra degree of complexity if there are translation Memories involved in the process, as follows. A translation memory is in essence a memory bank of previously translated target text. It is also an environment in which the translator works and has other advantages such as Glossaries to enhance quality and consistency and speed up the translation process. However, once the source text has been isolated we need to ensure that its format is compatible with the TM environment and that all translators are capable of working within the TM environment. Once this has been established we recuperate the previously translated text with the end result being that the translator receives a Translation Memory compatible file with all the previously translated text integrated. This is especially the case for software updates where large sections of the software remain the same which has an obvious saving on costs and time and ensures consistency and quality. The most obvious software translator environment of this type is alchemy catalyst. For a demonstration on a Translation memory environment please refer to the following link.

4. Translation and Revision of the software

Ok, so we send the translator the translation memory compatible files to translate, the most up to date Translation Memory (as they need to update it with their work) reference material such as Glossaries, previous User Guides…etc.. and the translator begins translation. During this stage one must bear in mind that the process can vary in many ways when we take into consideration that the translator may be in-house or external. Also, the translator may be responsible for typical localization bugs such as resizing of dialogues and menus and duplicate hot keys or this may be the role of the localization engineers after translation. The end product is an 80 to 90% localized pilot version. It is then revised by the translation company, the client or a third party depending on the software localization process defined at the start of the project?

5. Translated Software Build

During the next stage the pilot version is rebuilt for testing on various platforms.

6. Localization QA - Testing of localized software

Once rebuilt the pilot version is tested for functional bugs by the Localization QA team and linguistically tested, with the UI in context, by the translators or in some cases by third party linguists. The bugs are documented and sent to engineering in the case of functional bugs, or translation, in the case of linguistic bugs, to be fixed. This cycle continues until the translated software is bug free. The set-up of the phase can differ from company to company depending on the circumstances but in all cases it’s important to update the TMs with the linguistic fixes.

7.

Translation of other software language versions

Now that we have our pilot version localized and bug free, the process is in place to translate the other software language versions. I mentioned at the start of this article that in an ideal world the localized versions should be released on the same date as the master version however it’s usually impossible to achieve this and what usually happens is that certain languages are given priority depending on their market importance. The more important languages are called tier one languages and the less important languages for secondary markets are generally referred to as Tier 2 languages.
So there you have it in a nutshell, the software localization process but we must also bear in mind the additional components of the software such as the Online Help and documentation need to be localized in parallel with the software. Below are additional links for an insight into how these additional components are localized, the articles below belong to the series, "Localization: The definitive Guide" from One Stop Shop Translations:

NOTE: Please note that translation and localization are used interchangeably in this article.DEF: Translation is the communication of the meaning of a source-language text by means of an equivalent target-language text.DEF: Language localization is the process of adapting a product that has been previously translated into different languages to a specific country or region. Source: Wikipedia