Internationalization and the Common Desktop Environment

Multiple environments may exist within a common open system for support of different national languages. Each of these national environments is called a locale, which considers the language, its characters, fonts, and the customs used to input and format data. The Common Desktop Environment is fully internationalized such that any application can run using any locale installed in the system.

• Locale Management

• Font Management

• Drawing Localized Text

• Inputting Localized Text

• Extracting Localized Text

• Localized Resources

• Operating System Internationalized Functions

Locale Management

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.

The following are the functions used for locale management:

• XtSetLanguageProc()

• setlocale()

• XSupportsLocale()

• XSetLocaleModifiers()

Font Management

When rendering text in an X Windows™ client, at least two aspects are sensitive to internationalization:

• Obtaining the localized text itself

• Selecting the one or more fonts that contain all the glyphs needed to render the characters in the localized text.

Extracting Localized Text describes how to choose the correct fonts to render localized text.

Matching Fonts to Character Sets

A font contains a set of glyphs used to render the characters of a locale. However, you may also want to do the following for a given locale:

• Determine the fonts needed

• Specify the necessary fonts

• Determine the charset of a font in a resource file

• Choose multiple fonts per locale

The last two fields of a font XFLD identify which glyphs are contained in a font and which value is used to obtain a specific glyph from the set. These last two fields identify the encoding of the glyphs contained in the font.

For example:

-adobe-courier-medium-r-normal--24-240-75-75-m-150-iso8859-1

The last two fields of this XLFD name are iso8859 and 1. These fields specify that the ISO8859-1 standard glyphs are contained in the font. Further, it specifies that the character code values of the ISO8859-1 standard are used to index the corresponding glyph for each character.

The font charset used by the application to render data depends on the locale you select. Because the font charset of the data changes is based on the choice of locale, the font specification must not be hardcoded by the application. Instead, it should be placed in a locale-specific app-defaults file, allowing localized versions of the app-defaults file to be created.

Further, the font should be specified as a fontset. A fontset is an Xlib concept in which an XLFD is used to specify the fonts. The font charset fields of the XLFD are specified by the Xlib code that creates the fontset and fills in these fields based on the locale that the user has specified.

For many languages (such as Japanese, Chinese, and Korean), multiple font charsets are combined to support single encoding. In these cases, multiple fonts must be opened to render the character data. Further, the data must be parsed into segments that correspond to each font, and in some cases, these segments must be transformed to convert the character values into glyphs indexes. The XFontset, which is a collection of all fonts necessary to render character data in a given locale, also deals with this set of problems. Further, a set of rendering and metric routines are provided that internally take care of breaking strings into character-set-consistent segments and transforming values into glyph indexes. These routines relieve the burden of the application developer, who needs only the user fontsets and the new X11R5 rendering and metric application program interfaces (APIs).

Font Objects

This section describes the following font objects:

• Font sets

• Fonts

• Font lists