Is My Software Ready for Localization? (Part 1)
By Willem Stoeller
Vice President

A corporate globalization strategy provides you with specific localization requirements for each product-market pair. Nowadays, few companies apply the same localization requirements to all products and markets. In order to opti­mize the use of a localization budget, it is necessary in the early stages of product definition to define requirements for each product-market pair in terms of the following:

• Components to be localized – Core software, install, help, documentation, licenses, etc.



• Degree of localization – Beyond mere translation, there are varying degrees of cultural adaptation. The target user profile and the intended features of the software should drive this.



• Release dates relative to the one for the source version of the software application. Simultaneous release might be a necessity for a web-based application, while a two-month lag might be acceptable for a technical application with a relatively long product lifecycle.

These localization requirements in turn drive the interna­tionalization requirements for the software.

Next, you must consider whether your software applica­tion is usable in your target markets. To ensure good us­ability, consider these requirements:

• Support for the language of the target market – A user must be able to enter data into the software in his own language. The software must be able to process, store, and display this information without data corruption or data loss. In practice, this means that the software needs to support an encoding suitable for the language(s) of the target market. Support for Unicode solves this for all languages.



• Support for target platforms – The software application needs to support the hardware and operating systems in use in the target market.



• Support for regulatory requirements – The software application needs to comply with the regulatory requirements of the target market (such as the EC privacy requirements or the GB18030 certification requirements).



• Support for local conventions in terms of time, date, number, currency, sorting, and measurement units, etc.

Other components that increase the risk of poor usabil­ity include third party components and open-source com­ponents in the software application. Naturally, these and all the above usability requirements should be validated as part of the software QA.

Go Back