For the desktop, most single-display clients operate in a single locale that is determined at run time from the setting of the environment variable, which is usually $LANG. The Xm library (libXm) can only support a single locale that is used at the time each widget is instantiated. Changing the locale after the Xm library has been initialized may cause unpredictable behavior.
All internationalized programs should set the locale desired by the user as defined in the locale environment variables. For programs using the desktop toolkit, the programs call the XtSetLanguageProc() function prior to calling any toolkit initialization function; for example, XtAppInitialize(). This function does all of the initialization necessary prior to the toolkit initialization. For nondesktop programs, the programs call the setlocale() function to set the locale desired by the user at the beginning of the program.
Locale environment variables (for example, LC_ALL, LC_CTYPE, and LANG) are used to control the environment. Users should be aware that the LC_CTYPE category of the locale is used by the X and Xm libraries to identify the locale-specific features used at run time. Yet, the LC_MESSAGES category is used by the message catalog services to load locale-specific text. Refer to "Extracting Localized Text" for more information. Specifically, the fonts and input method loaded by the toolkit are determined by the setting of the LC_CTYPE category.
String encoding (for example, ISO8859-1 or Extended UNIX Code (EUC), in an application's source code, resource files, and User Interface Language (UIL) files) should be the same as the code set of the locale where the application runs. If not, code conversion is required.
All components are shipped as a single, worldwide executable and are required to support the R5 sample implementation set of locales: US, Western/Eastern Europe, Japan, Korea, China, and Taiwan.
Applications should be written so that they are code-set-independent and include support for any multibyte code set.