One model that has been used to create an application in different languages is to first develop the application in one language, often English, and then create versions of it for other languages--a process that may involve modifying the program code. While this model was sufficient for many years, it is now considered obsolete because it has several severe shortcomings: high development and translation cost; the language versions are sometime incompatible with one another; and in many cases each language version must run on its own platform.
Until the emergence of the Internet, a server and its client could be assumed to share the same language. But in a global e-business environment, a server-based application can be accessed from anywhere in the world by clients with different language preferences. While it is possible to deploy an application across multiple servers with one server per language (and a separate server to direct the clients' requests based on each user’s language preference), it is far from ideal. An installation with separate servers dedicated to each language requires more computing power than necessary, and it may not be responsive to user requests because it cannot balance workload among the servers.
Unicode and standard libraries such as ICU make it possible to develop a single executable that can work with all major languages, and such an application will not require one server per locale. Supporting a language requires more than just handling the scripts. The application needs to display program information (menus, prompts, etc.) in the user's preferred language, and it also needs to correctly display dates, time, currency symbol, mailing address, etc.
The simplest way to create and manage language-specific (or locale-specific) information is through the use of localization packs. A localization pack is essentially a separate application module that contains language-and locale-specific information which is acquired by the application during execution. Changing a language simply means replacing one pack with another; the program code does not need to be re-compiled. A server-based application should also be designed to support multiple localization packs simultaneously so that it can meet the needs of users from different parts of the world. The following diagram illustrates how a localization pack can contain not only translatable text, but also day formatting and collation sequence.
Figure 1
Another advantage of a localization pack architecture is that it reduces the chances of mistakes during translation. When a translator works directly with program code, there is a chance that the program code may be changed inadvertently. Such errors are not possible with a localization pack.
It is not always necessary to create a localization pack architecture from scratch. Modern platforms provide amply support such an architecture. Java, for example, provides resource bundles and APIs to access them within a program. ICU also provides a similar architecture that be used across platforms. | 
