The current prevailing practice is for applications to place text in resource strings which are loaded during program execution as needed. These strings, stored in resource files, are relatively easy to translate. Programs are often built to reference resource libraries depending on the selected locale data.

Thus to get an application to support multiple languages one would design the application to select the relevant language resource file at runtime. Resource files are translated to the required languages. This method tends to be application-specific and at best, vendor-specific. The code required to manage date entry verification and many other locale-sensitive data types also must support differing locale requirements. Modern development systems and operating systems include sophisticated libraries for international support of these types. However, many development environments still lack full Unicode support, which drastically hampers the translation effort, especially to East Asian languages.

New methods are evolving all the time to handle these complex issues. One such method, known as NLSO or Natural Language Support Objects uses databases to store resource strings. Another approach is the elimination of all references to culture, politics, history, etc.; avoidance of images (especially text embedded in images); and use of a controlled language. An example of an implementation of these principles is Uwe Muegge's website that uses Google's language tools to create virtual versions of his site in eleven languages.

Pseudolocalization is a software testing method that is used to test a software product's readiness for localization.

Related Articles:

Project scheduling :: Difficulties Localizing Software :: Methods for Localizing Software :: How Localization is Usually Organized :: Software Localization Tools