Localization Done Right Guarantees Delighted Clients: High Level Localization Guidelines

Leave a comment

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.

paul_1_left_to_right

Form in US English (left to right)

paul_2_right_to_left

Form in Urdu (right to left )

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.

paul_3_pseudo_japanese

A nonsense pseudo Japanese translation showing that formatting is preserved

 

paul_4_glossary

Glossary with expected translations of specific words

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.

paul_5_untranslated

Label left untranslated and perhaps image text, other English text is OK.

 

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.

Author: bridge360blog

Software Changes Everything.... Bridge360 improves and develops custom application software. We specialize in solving complex problems at every phase of the software development lifecycle, removing roadblocks to help our clients’ software and applications reach their full potential in any market. The Bridge360 customer base includes software companies and world technology leaders, leading system integrators, federal and state government agencies, and small to enterprise businesses across the globe. Clients spanning industries from legal to healthcare, automotive to energy, and high tech to high fashion count on us to clear a path for success. Bridge360 was founded in 2001 (as Austin Test) and is headquartered in Austin, Texas with offices in Beijing, China.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s