Many enterprise applications do not provide all the languages that businesses require to support employees, partners and customers. Depending on the language and software application, localization can present formidable hurdles for software vendors. Here are the 10 biggest pitfalls associated with software application localization projects and how to deal with them.

1. Programming Hygiene

Even companies with mature development teams and top-tier technical talent have difficulty delivering truly internationalized code. The most common stumbling block is not enforcing pre-established development principles (such as externalizing text strings, providing database columns for multilingual data storage, etc.) due to product release deadlines, lack of sufficient QA resources or both. This often leads to programming hygiene deterioration and developers checking in code that is not internationalized.

2. Legacy Code

It’s rare for a software development team to build a new product from scratch. Even when completely new functionality is developed, companies often rely on legacy code to get a substantial leg up in terms of time-to-market. Very often this legacy code is not internationalized and prevents the entire product from supporting multiple languages

3. Data Storage

Even when code is internationalized, some software products do not configure the data repository so that it can store and retrieve international character sets. If this is the case, internationalizing the product will require new configurations and formats be added to the data store. This not only adds another layer of complexity to the development process, but also significantly expands the test matrix.

4. Functional Internationalization

In addition to language, internationalization also affects other elements such as local business rules and regulations, currencies, date formats, currency symbols, etc. Although this is not a “pitfall” per se, it is something that must be accounted for by developers. Fortunately from a product development point of view, adding functional internationalization typically only affects specific modules in a somewhat predictable way.

5. Localization Testing

Once a product is internationalized and translators have localized the software, the application must be tested. This can be a formidable task for development teams which have been working in a single-language environment, since they must now test software that generates on-screen outputs in a foreign language. Developers often use clever tactics to get around this problem. Such as using predictable, but differently formatted English language text in place of the original text to ensure that the product is properly internationalized. However, this does not address localization testing. For example, right-aligned fields cannot be properly viewed in Chinese; Right-to-left languages may require layout changes in some screens; and German translations may require more space than is available on the screen.

6. Universal Upgrade Requirement

Once a product is internationalized and localized, customers will need to upgrade the software and the underlying data store. This is necessary since the product now has a new data store format to support international characters. This can be especially painful, since the upgrade is universal (i.e. it affects customers who require the local language and those who are only using the software in English). For mission critical applications, upgrades can not only cause business disruption but also pose a significant risk to the business if something goes wrong.

7. Customizations and Add-ons

Virtually all enterprise software is deployed with substantial customization and same-source or third-party add-ons. Therefore, localization must also extend to all add-ons and customizations that may already be in place. Otherwise, the internationalized and localized version of the product will not function properly.

8. Data Fragmentation

In a multi-language system, the same data will be written differently in each language. If a product’s deployment architecture relies on local processes for creating categorical data such as “supplier name” this may cause inconsistencies. For example, business units in different parts of the world may refer to the same supplier using different names (each in their own language). This would break functionality in a product that provides high-level summary or analytical information, since individual rows that represent the same data are not categorized together.

9. Upgrade Barriers

When software is not fully internationalized and localized (e.g. some modules or add-ons are not fully localized), customers are tempted to make database-level modifications using in house IT, software vendor or third-party resources. This can have a fatal impact during upgrade cycles since these changes are not validated in the new version delivered by the vendor.

10. Separate Source Trees

This is possibly the worst “pitfall”. Occasionally, a software vendor will make language or functional changes to one copy of their source-code to address a specific market. This may seem like an innocuous strategy, but it can have a devastating impact on support and upgrade operations. That’s because the source-code base has been doubled, so every downstream process – QA, support, training, etc. has also been doubled.

This complexity explains why most software vendors have limited globalization to only a few flagship products in their portfolio. It is also preventing many companies from fully capitalizing on the market potential for their products.

Fortunately, new advances such as run-time approaches to software localization eliminate a lot of the pitfalls described above. These methods can create a “skin” on top of an application’s existing interface to enable users to operate the software in the language of their choosing. It also eliminates the need for conventional internationalization and provides a cleaner separation between software development and localization efforts. For software vendors, implementing language localization at run-time can dramatically reduce the cost, complexity and time it currently takes to globalize products using traditional approaches.

About the Author: Atul Tulshibagwale is CEO of LinguaNext (www.linguanext.net), a provider of application language management technology.