by Paul Cooper, Senior Localization Engineer
Any time software is destined for the global market or for a diverse audience within a region, it is well worth planning the localization effort. Seemingly small errors in wording or presentation can ruin the professional aspects of a product, leaving instead an impression of amateurism or cultural indifference. The following steps are a guide to the localization process to produce successful translation packages.
Internationalization: This process is designed to make localization easier to implement. Its goal is to reduce local dependencies and cultural bias that could hinder localization efforts. Western text is mostly written left to right. However in the Middle East, writing right to left is common.
Imagine how that could affect the display of a data entry page, especially if the content has to support both writing directions. Other examples of cultural/local bias include number/date representations as well as address/phone number specification. Initial planning for cultural neutrality is difficult, therefore it’s advisable to find internationalization specialists to assist and provide best practices.
Separation: Invariant content should be separated from translatable localization content. In code this may mean using property type files to hold translatable strings. In the case of images containing text, the text can be stored on a separate layer from the actual image. Whatever presentation medium is used, separating content makes localization easier and reduces the likelihood of translation errors. Separation can also prevent accidental leaking of IP or other sensitive material when sending content for translation.
Pseudo Translation: This step mimics the translation process from end-to-end to verify the actual translation can later be successfully produced and applied. Despite diligent application internationalization and separation steps, it’s still possible for errors to creep into the localization process. For instance, there may be reliance on a tool or process to extract/filter translatable content. In theory the tool should work, but in practice it may be too difficult to implement or it produces files with too little or too much content. It’s better to know about such glitches early so that remedial strategies can be put in place and scheduled.
Supporting Documentation: When the product is technical in nature, having terms with very specific meanings, then a glossary of those terms should also be supplied. Also, any invariant text that remains in the translation package, such as trademarked terms or phrases, should be listed so the translation tools can be adjusted to ignore those items. In the case of a GUI translation, access to the running application or a comprehensive set of screen shots should be provided so the translators can see the term in context.
Translation Packaging: Given all of the previous steps have been followed this will simply be putting all of the translatable content into a package (file/directory structure) determined from the pseudo translation. The supporting documentation should also be included in a separate folder. After the translation each language is returned in its own package.
Post Translation: Some projects benefit from Linguistics Testing (LT) as a quality assurance step after the translations have been applied. In the LT process, translators exercise the product (or view screen shots of the translated product) to verify the presentation’s correctness in context. This process can find those translatable items that were not sent in the translation packet or were mistranslated due to lack of context within the translation package.
Planning the localization effort, from requirements through testing and implementation, allows your message to enter global markets the way you intend and protected from missteps and misunderstandings. Working with an experienced Localization and Internationalization QA team is a smart first step in the planning process. To learn how Bridge360® can support your product around the world, click here.