Localization Model (Windows)

The Windows-native localization model differs from that of IBM C and C++ Compilers in two ways:

1. Windows and IBM C and C++ Compilers Locales
The Windows-native localization model (as supported by the Win32 APIs) is not the same as the POSIX model supported by IBM C and C++ Compilers. For this reason, changing the country via the Control Panel will not alter the cultural behavior of your IBM C and C++ Compilers application. Similarly, changing the LC_ environment variables will have no effect on an application calling native-Windows APIs.

Further, confusion may arise because both the Windows operating system and IBM C and C++ Compilers files are known as locales and, while there is some similarity between the two, each is a distinct implementation.

2. Windows ANSI and Windows OEM Code Pages
The Windows operating systems support two classes of code page:

  1. American National Standards Institute (ANSI)
  2. Other Equipment Manufacturers (OEM).

Because locales are bound to a specific code page, there must be a separate locale for each country-language-codepage combination. If you want the locale that is bound to the ANSI code page, you must specify the codeset-qualified name that identifies the code page. For example, the following specifies the English, Great Britain, code page 1252:

en_GB.IBM-1252

For locales bound to OEM code pages, you should specify only the language-country name. For example, the following identifies French Canada, using the currently active code page:

fr_CA

Windows controls (e.g. entry fields, list boxes, menus, multi-line edit, etc.) use the ANSI code page. If the source or target of the data is a Windows control, your application must use the locale bound to the ANSI code page. Otherwise, you can use the locale bound to the OEM code page.



Internationalization
Localization and Locales


Make Your Program International