The Concept of Internationalization

Internationalization, also abbreviated as i18n, is the process of designing an application, such that it can be adapted to various languages and regions without performing engineering/code changes.

Localization, on the other hand, is the process of adapting software for a specific region or language by adding locale-specific components and translating text. Other types of data, such as sounds and images, may require localization if they are culturally sensitive. Localizers also verify that the formatting of dates, numbers, and currencies conform to local requirements.

An internationalized program has the following characteristics:

Internationalization affects every phase of the software development process. The impact is most critical during the following stages:

Internationalization (and subsequent localization) introduces some very significant additional development costs, many of them being recurring (per-release) costs.

The introduction of a product into the international markets, places significant burden on the requirements phase.

First, a whole host of new questions need to be answered. These questions are the ones, whose answers for the domestic market were too obvious and did not deserve taking up space in the requirements document.

Next, these questions need to be addressed per-locale (i.e. per target market) and per-interface (e.g. the user interface may need to be "more localized" than the installation utility).

Finally, there is often a need to begin calculating the scope of effort as early in the process as possible. For this, you need to understand the high-level requirements, but you may not need all the details. Therefore, it often makes sense to break the requirements gathering phase into two phases. This ensures that the defining the scope does not need to wait for the completion of the full set of requirements.

This phase involves:

Internationalization impacts architecture in several ways, but the most significant issue is the flow of text through the system. In software systems of any complexity, non-ASCII (particularly non-Latin-1) text will need to be encoded differently at different points, as it flows through the system. It is also converted from one encoding to another for different interfaces. In international software, these conversion points must be carefully controlled to preserve the integrity of textual data.

Other architectural issues include the normalization and formatting of other locale-sensitive data types (e.g. dates, times, and numbers) and mechanisms for retrieving locale-appropriate UI text and messages. The task of creating a product architecture that addresses these issues is known as architectural design.

If you are re-engineering a domestic product into an international product, you need to precede this effort with a current-state analysis of the product architecture. This is done with respect to specific factors that will affect internationalization. This task is known as architectural analysis.

If you are planning to localize your product, you now have a new kind of "customer": The Localizer. The better you serve this customer, the lower your localization cost will be. Lower localization cost begins with a well-organized (and documented) localization kit. This kit contains all the files, build utilities, etc. that the localizer will need to localize your product.

One of the objectives of analysis and design is to design a localization kit that will maximize the localizer's productivity, while minimizing their dependency on your engineering team during the localization process.

The need to perform analysis and design for the software itself is probably the most obvious at this stage. Source code analysis is one of the methods employed to find answers to questions raised during architectural analysis. It is a source of important information about the scope of the effort, as well as the nature of certain tasks that will be included in the project plan.

Infrastructure analysis involves looking at the infrastructure that you use to build and maintain your product (build procedures and utilities, source code control, and bug tracking) to identify how it will need to change, as you enter international markets.

Global products generally require two QA phases:

1. Internationalization QA:
It validates the internationalization work and ensures that the product is ready to be localized. Internationalization testing must go beyond breaking the code-page dependency in the test data, and checking for cultural accuracy.


2. Localization QA:
It validates the localization work and ensures that the product is ready for the end users. Localizability testing verifies that the UI of the program, being tested, can be easily translated to any target language without re-engineering or making code modifications.

Third-party software presents a particularly acute risk. It is easy to underestimate third-party software issues for three reasons:

1. It is easy to forget it is there.
This is particularly true for software that has been included from the beginning, performing some internal low-level function, that has worked fine, untouched, for years. The age itself should be a red flag.


2. It is easy to assume that your suppliers are more advanced than you are, in terms of internationalization
. This is another dangerous assumption.


3. It is easy to be misled by vague claims made by the supplier.
Just because a product has, "International support" does not mean it supports your target markets. Moreover, just because a product supports your target markets does not mean it supports your requirements for those markets.

• No source.
You may not have the source code.


• No support.
The supplier may no longer exist, or may no longer support the product or version you are using.


• No control.
You may have insufficient influence over the supplier to convince them to address the issue in time to meet your schedule needs.

Because of these dangers, third party software require careful attention.

Many programs are not internationalized when first written. These programs may have started as prototypes, or perhaps they were not intended for international distribution.

Text messages are the most obvious form of data that varies with culture. However, other types of data may vary with region or language. The following list contains examples of culturally dependent data:

1. Messages



2. Labels on GUI components



3. Online help



4. Sounds



5. Colors



6. Graphics



7. Icons



8. Dates



9. Times



10. Numbers



11. Currencies



12. Measurements



13. Phone numbers



14. Honorifics and personal titles



15. Postal addresses



16. Page layouts

Many databases like Oracle and SQL Server support Unicode character set. If one needs to store multiple language information then Unicode character set should be used.