Localizability and World-Readiness for Software, Part Three

In part two of this series we looked at why context is king in software localization. In the third and final part, we’ll examine a proactive localizability development model and delve into the phenomenon of pseudo-localization.

The major problem with incorporating localization late in the development process is that it complicates the process of resolving language-related issues that are discovered during or after translation and during localization testing. These issues are likely to require some development re-work and are likely to happen at a very critical moment in the timeline – right before the release. A study by the Systems Science Institute at IBM found that the cost of fixing an error found after product release was four to five times as much as one uncovered during design.

For localized products, these costs have the potential to be multiplied by the number of target languages. If localizability testing is not carried out before English approval, each testing team for each target language will spend time discovering and reporting the same issues. They will then each need to run regression testing on the same bugs. This can be avoided if localizability testing is brought forward in the product development cycle. If we modify the earlier process a little (by running localizability testing in sync with usability testing) we can avoid these issues altogether. The revised process flow below shows a pseudo-translation testing phase in orange.

This means that developers will exchange localizable files with the translation team even before source content is approved. Introducing pseudo-translation testing helps to identify language-related issues early in the process, so there is still enough time to go back to developers and fix any language-related issues. Once the source content is approved, it can be translated and linguistically tested, safe in the knowledge that the number of issues requiring developer intervention has been minimized because they were discovered and fixed much earlier in the process. 

Pseudo-localization

At its most basic, pseudo-localization refers to a very rapid and cost-effective method of mimicking the effects of the translation process – without the costs and scheduling impact of a real translation. Pseudo-localization simulates the translation of all resource strings, and usually involves the following:

• Replacing some English characters with similar non-English characters
• Adding extra characters to simulate text expansion
• Adding prefixes and suffixes to mark the boundaries of a string
• Using Unicode characters for all resources

All these changes can be automated, so all UI resources can be modified using similar patterns that make issues easy to identify in newly built resources. Pseudo-translated resources can be used to rebuild an application and test it. The way it functions should be the same as the original version. Thanks to the patterns used while pseudo-translating resources, it is easy to detect the following issues:

• Strings that were hard-coded and were not moved to the localizable resources
• Strings that were built from other strings by concatenation or replacing some parts of the string – these strings will often not work in languages different from the source language
• Any Unicode-incompatible functions that process or display text
• Any other display issues like incompatible fonts, truncated strings, or unexpected space limitations

Code reviews: Anticipating the future and learning from the past

 Just as complex projects should be followed by a post-project review, it is also worth closing the development loop by creating and maintaining code development guidelines that include localization-related guidelines. These guidelines should reflect the results of code audits and localization process issues that were fixed in the past. For projects with large volumes of code, there are third-party tools that can automate the code review process.

Localization providers are typically happy to participate in this process, as it helps them to perform great work the first time around in the future. In conclusion, world-readiness is perfectly compatible with the development process as long as you take steps to bring your localization partners onboard early on, perform pseudo-translations to test localizability before translations begin, and use a format that allows linguists to do their jobs.

Want to know more?

• Blog: Localizability and World-Readiness for Software, Part One
• Blog: Localizability and World-Readiness for Software, Part Two
• Software Localization Services