Localizability and World-Readiness for Software, Part One

Software errors found after release can cost up to five times as much to fix as those uncovered during the design stage. Incorporating localization from the beginning can lower your company’s costs – and your developers’ blood pressure!

It’s easy for localization to be overlooked when a software development team is in the product design phase. Development teams are busy with gathering user requirements, developing components, and testing usability in the source language (probably English) – until the moment when the product manager says, “This is great! Let’s sell it in 15 countries!”

However, if localizability hasn’t been built into the product, developers can be thrown into a costly, time-consuming spiral of retrofitting global needs onto a product, delaying global release cycles and creating ugly provisional workarounds that add unnecessary complications to both native and international release processes. What seemed like a great idea – to amortize development costs faster through global expansion – can rapidly become the source of sleepless nights for both the product manager and the development team.

Taking it worldwide

The goal of software development for the global marketplace should be to create a “world-ready” application. This process is often referred to as internationalization, and it makes sure that software can be run anywhere and in any language. This means the application should be able to support any regional time and date or numbering formats and should be ready to be translated into any language, even bi-directional languages or those using different scripts and alphabets.

The key to localizability is designing software and resources that don’t require re-engineering or code modification after the translation process. The first step on the road to a “world-ready” application is achieving the clear separation of user interface (UI) resources from functionality-related resources. The best way to do this is by using file formats that suit localization teams, which enables both the use of professional translation tools and potential automation, which becomes a key element when developing and localizing in Agile environments. The next step is measuring the success of any localizability efforts, and the easiest way to do that is by running localizability testing tasks.

Function and process

There are typically three interdependent functional teams involved in launching a global product: developers, translators, and testers. As the process flow diagram illustrates, usability testing takes place prior to the launch of software in its original language as well as after translation. Localization testing can result in two types of issues:

Translation issues can be fixed by getting a linguist to amend the translation. This type of issue normally occurs either because the original translation doesn’t reflect a string’s real meaning in the context of the running application or because a string needs to be shortened to match the space available within the user interface.
Functional issues are issues that need to be routed back to developers, and which cannot be fixed by making a linguistic change. These can range from bugs which are introduced because of the translated language, string length issues which cannot be fixed by reducing the length of a translation or functional issues which were not apparent in the English build.