### 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