┌──────────────────────────────────────────────────────────────────────┐ │XPG4 provides facilities to generate an internationalized application │ │and localized objects. │ └──────────────────────────────────────────────────────────────────────┘
The major facilities of XPG4 Internationalization are listed below:
The L10N process generates objects containing information on language and cultural convention which is called locale (refer to What Is Locale?). XPG4 defines API to access the locale objects and utility to create a new locale.
The wchar_t data type, which is originated from the C language, is a key to code page independence. It is an integral type which can store every member of the largest character set specified among the supported locales. So far as characters are represented in wchar_t objects, a program does not need to consider the code page and the encoding scheme. XPG4 defines various API for handling wchar_t . A program should process all text using these API. For more details, refer to Multi Byte vs. Wide Character.
In a heterogeneous code page environment, an application needs to convert text data from one code page to another, even within the same language and country. For example, an OS/2 application accessing to S/390 data may require such conversion. XPG4 provides code conversion API and utility, iconv, but this document does not cover them. Please refer to VAC++ Programming Guide for more details.
One of the keys to language independence is the PII isolation. PII must be extracted from the executable modules for translatability and for ease of selecting PII for appropriate language at run time. XPG4 defines the Message Catalog system for message texts used in an internationalized program, but OS specific modules such as PM resource files or IPF files are out of XPG4's scope. This document describes some hints & tips for PM resources isolation (refer to Preparing for PII Translation).
By using these XPG4 facilities, an application can be written in a language and code page independent manner. As a result, a single executable module of an application runs equally well on OS/2 in any country configuration though there are currently several national language versions of OS/2. This eliminates the need for national language versions, thus reduces the development, manufacturing and distribution costs.
┌──────────────────────────────────────────────────────────────────────┐│The selection of Localization features is user-definable through │ │environment variables. │ └──────────────────────────────────────────────────────────────────────┘This mechanism permits the dynamic binding of the locale files. The language and cultural convention to be referred to by an application is determined by the end user, not by a system or the application.
Let's think about the current OS/2 application. Due to the system design, most of the information on cultural convention is set to a work station, not to an application. However, by using XPG4 Internationalization facilities, the application can use the different cultural convention even on the same work station by setting the environment variables.
Please refer to In the Beginning of All - setlocale for the description of the environment variables.
┌──────────────────────────────────────────────────────────────────────┐ │Supporting new environment, encoding scheme, language or culture can │ │easily be achieved by adding a new locale. │ └──────────────────────────────────────────────────────────────────────┘
In AP, there are many countries whose national languages need to be supported. By using XPG4 Internationalization facility, an application can automatically support a new environment when a new locale is provided.
For more detailed information on the concept of the Internationalization, refer to X/Open Internationalization Guide Version 2 issued by X/Open.