HP OpenVMS Systems Documentation |
Common Desktop Environment: Internationalization Programmer's Guide 2 Internationalization and the Common Desktop EnvironmentContents of Chapter: 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 ManagementFor 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
Locale environment variables (for example, 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: 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:
Font ManagementWhen rendering text in an X Windows client, at least two aspects are sensitive to internationalization:
Matching Fonts to Character SetsA 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:
For example:
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 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 Font ObjectsThis section describes the following font objects:
Font SetsGenerally, all internationalized programs expecting to draw localized text using Xlib are required to use anXmFontSet for specifying the locale-dependent fonts. Specific fonts within a font set should be specified using XLFD naming conventions without the charset field specified. The resource name for an XFontset is *fontSet . Refer to "Localized Resources" for a list of font resources.
Applications directly using Xlib to render text (as opposed to using
FontsInternationalized programs should avoid using fonts directly, that is,XFontStruct , unless they are being used for a specific charset and a specific character set. Use of XFontStruct may be limiting if the server you are connecting to does not support the specific charsets needed by a locale. The resource name for an XFontStruct is *font.Font ListsAll programs using widgets orXmString to draw localized text are required to specify an XFontList name for specifying fonts. A font list is a list of one or more fontsets or fonts, or both. It is used to convey the list of fonts and fontsets a widget should use to render text. For more complicated applications, a font list may specify multiple font sets with each font set being tagged with a name; for example, Bold, Large, Small, and so on. The tags are to be associated with a tag of an XmString segment. A tag may be used to identify a specific font or fontset within a font list.Font Set and Font List SyntaxTable 2-1 shows the syntax for a font set and font list.
Table 2-1 Font Set and Font List Syntax Here are some examples of font resource specifications:
The preceding fontList specifies a fontset, consisting of one or more 24-point Adobe Courier fonts, as appropriate for the user's locale.
This fontList specifies a fontset consisting of an 18-point Courier font (if available) for some characters in the users data, and an 18-point Gothic font for the others.
Motif-based applications sometimes need direct access to the font set contained in a font list. For example, an application that uses a
Font FunctionsThe following Xlib font management API functions are available:
Font CharsetsTo improve basic interchange, fonts are organized according to the standard X-Consortium font charsets.Default Font Set Per Language GroupSelecting base font names of a font set associated with a developer's language is usually easy because the developer is familiar with the language and the set of fonts needed.Yet, when selecting the base font names of a font set for various locales, this task can be difficult because an XLFD font specification consists of 15 fields. For localized usage, the following fields are critical for selecting font sets:
Throughout this documentation, the following convention should be used when specifying localized fonts:
The following describes the minimum set of recommended values for each field to be used within the desktop for the critical fields when specifying font sets in resource (app-defaults) files.Latin ISO8859-1 Fonts
Other ISO8859 FontsThe same values defined for ISO8859-1 are recommended.JIS Japanese Font
KSC Korean Font
Note: The FAMILY_NAME values may change depending on the official romanization of the two common font families in use. As background, Totum corresponds to fonts typically shipped as Gothic, Kodig, or Dotum; Pathang corresponds to fonts typically shipped as Myungo or Myeongjo. CNS Traditional Chinese Font
GB Simplified Chinese Font
Drawing Localized TextThere are several mechanisms provided to render a localized string, depending on the Motif or Xlib library being used. The following discusses the interfaces that are recommended for internationalized applications. Yet, it is recommended that all localized data be externalized from the program using the simple text.Simple TextThe following Xlib multibyte (char*) drawing functions are available for internationalization:
XmString (Compound String)For the Xm library, localized text should be inserted into XmString segments usingXmStringCreateLocalized() . The tag associated with localized text is XmFONTLIST_DEFAULT_TAG , which is used to match an entry in a font list. Applications that mix several fonts within a compound string using XmStringCreate() should use XmFONTLIST_DEFAULT_TAG as the tag for any localized string.
More importantly, for interclient communications, the
A localized string segment inside an The following is an example of creating a font list for drawing a localized string:
A localized string can be written in resource files because a compound string specified in resource files has a locale-encoded segment with Xm_FONTLIST_DEFAULT_TAG . For example, the fontList resource in the following example is automatically associated with XmFONTLIST_DEFAULT_TAG .
The following set of XmString functions is recommend for internationalization:
XmString functions is not recommend for internationalization because it takes a direction that may not work with languages not covered:
Inputting Localized TextInput for localized text is typically done by using either the local input method or the network-based input method.The local input method means that the input method is built in the Xlib. It is typically used for a language that can be composed using simple rules and that does not require language-specific features. The network-based input method means that the actual input method is provided as separate servers, and Xlib communicates with them through the XIM protocol to do the language-specific composition. Basic Prompts and DialogsIt is strongly recommended that applications use theText widget to do all text input. Input within a DrawingArea WidgetMany applications do their own drawing within a widget based on input. To provide consistency within the desktop environment,XmIm functions are recommended because the style and geometry management needed for an input method is managed by the VendorShell widget class. The application need only worry about handling key events, focus, and communicating the current input location within the drawing area. Using these functions requires some basic knowledge of the underlying Xlib input method architecture, but a developer need only be concerned with the XmIm pieces of information.Application-Specific and Language-Specific Intermediate FeedbacksSome applications may need to directly display intermediate feedback during preediting, such as when an application exceeds the functions supplied by Xlib. Examples of this include for PostScript rendering or using vertical writing.
The core Xlib provides the common set of interfaces that allow an application to display intermediate feedback during preediting. By registering the application's callbacks and setting the preediting style to Applications intended to do sophisticated language processing may recognize extensions within a specific XIM implementation and its input method engines. Such applications are on the leading edge and will require familiarity with details of the XIM functions. Text and TextField WidgetFor basic prompts and dialogs, theText or TextField widget is recommended. Besides resources, all of the XmTextField and XmText functions are available for getting and for setting localized text inside a Text[Field] widget.
Most
The width of a
The following section identifies the set of functions available for applications that are used to manage input methods. For applications that use the Character Input within Customized Widgets Not Using Text[Field] WidgetsIn some cases, an application may obtain character input from the user but does not use aTextField or Text widget to do so. For example, an application using a DrawingArea widget may allow the user to type in text directly into the DrawingArea. In this case, the application could use the Xlib XIM functions as described in later sections, or alternatively, the application may use the XmIm functions of Motif 1.2. The XmIm functions allow an application to connect to and interact with an input method with a minimum of code. Further, it allows the Motif VendorShell widget to take care of geometry management for the input method on the application's behalf.
Although the
Note: The Motif 1.2 XmIm functions do not support preedit callback style or status callback style input methods. The preedit callback can be used by the Xlib API. For more information, see "XIM Management".
Following are the
XmImSetValues() and XmImSetFocusValues() functions allow the application to pass information needed by the input method. It is important for the application to pass all values even though not all values are needed (for each supports preedit and status style). This is because the application can never be sure which style has been selected by the user or the VendorShell widget. Following are the arguments and data types of each value that should be passed in each call to the XmImSet[Focus]Values() function.
XmIm functions are used in the following manner:
XIM ManagementFollowing are the XIM management functions.
XIM Event HandlingFollowing are the XIM event handling functions:
XIM CallbackX Input Methods (XIMs) provide three categories of callbacks. One is preedit callbacks, which allow applications to display the intermediate feedbacks during preediting. The second is geometry callbacks, which allow applications and XIM to negotiate the geometry to be used for XIM. The third is status callbacks, which allow applications to display the internal status of XIM.
Table 2-2 XIM Callbacks Extracting Localized TextAlthough there are different methods to localize an application, the general rule is that any language-dependent information is outside the application and is stored in separate directories identified by a locale name.This section describes how the user, the application developer, and the implementation combine to establish the language environment of the application. Two general approaches to localizing applications are also discussed. The following three methods can be used:
Resource FilesThis is the GUI toolkit mechanism for customizing all sorts of information about an application. The Intrinsic library (libXt) provides a sophisticated mechanism for merging the command-line options, application-defined resources, and user-defined resources. Resource files can be used for extracting localized text. The difference between resource files and message catalogs is that the resource database is compiled each time it is loaded. As such, care should be taken when deciding which strings to place in resource files and which to place in message catalogs.Also note that the Xm library functions do not depend on the LC_MESSAGE category when specifying the location from which localized resources are loaded. Refer to the XtSetLanguageProc() man page for more information. Message CatalogsThis is the traditional operating system mechanism for accessing external databases containing localized text. These functions load a precompiled catalog file that is ready to be accessed. They also provide defaults within the actual program for cases when no catalogs may be found.The messaging support is based on both the XPG4 and System V Release 4 (SVR4) interfaces for accessing message catalogs. Private FilesPrivate databases can be used by applications to provide generic, customized databases for more than just localization text. Usually, such databases do contain text. It is recommended that if the database is to be spread out over many files, some run-time indirect access of localized text be provided. Without this access, localization for the average user is a difficult effort. Generally, such private file formats are discouraged by groups doing localization. But problems are reduced if a tool is provided specifically for localization of text only.Message GuidelinesMessage guidelines foster consistent formatting of message and help information. They also promote creation and maintenance of messages that can be easily understood by inexperienced English-speaking end users, as well as by inexperienced translators. Use these guidelines to create message files that are consistent in language and clear in meaning. Distribution of these guidelines enable programmers and writers to coordinate their message-writing efforts. Default messages, external message files, and planned delivery of translatable messages are required for each executable to fully implement international language support.Message Extraction FunctionsOne of the requirements of internationalizing programs (basic commands and utilities inclusive) is that the messages displayed on the output devices be in the language of the user. As these programs may be used in many countries (international locales), the messages must be translated into the various languages of these countries.There are two sets of message extraction functions in the desktop environment: XPG4 functions and Xlib functions. XPG4/Universal UNIX Messaging FunctionsThe XPG4 message facility consists of several components: message source files, catalog generation facilities, and programming interfaces. Following are the XPG4/Universal UNIX message functions:
XPG4 Messaging ExamplesThere are three parts to this example which demonstrates how to retrieve a message from a catalog. The first part shows the message source file and the second part shows the method used to generate the catalog file. The third part shows an example program using this catalog.
Message Source FileThe message catalog can be specified as follows:
Generation of Catalog FileThis file is input to thegencat utility to generate the message catalog example.cat as follows:
Accessing the Catalog in a Program
Xlib Messaging FunctionsThe following Xlib messaging functions provide a similar input/output (I/O) operation to the resources.
Xlib Message and Resource FacilitiesPart of internationalizing a system environment, toolkit-based application is not having any locale-specific data hardcoded within the application source. One common locale-specific item is messages (error and warning) returned by the application of the standard I/O.In general, for any error or warning messages to be displayed to the user through a system environment toolkit widget or gadget, externalize the messages through message catalogs.
For dialog messages to be displayed through a toolkit component, externalize the messages through localized resource files. This is done in the same way as localizing resources, such as the
For example, if a warning message is to be displayed through an
Localized resource files can be put in the /usr/lib/X11/%L/appdefaults subdirectories, or they can be pointed to by the Localized ResourcesThis section describes which widget and gadget resources are locale-sensitive. The information is organized by related functionality. For example, the first section describes those resources that are locale-sensitive for widgets used to display labels or to provide push-button functionality.Labels and ButtonsTable 2-3 lists the localized resources that are used as labels. Many of them are of typeXmString . The rest are of type color or char*. See the Motif 1.2 Reference Manual for detailed descriptions of these resources. In each case, the application should not hardcode these resources. If resource values need to be specified by the application, it should be done with the app-defaults file, ensuring that the resource can be localized.
Only the widget class resources are listed here; subclasses of these widgets are not listed. For example, the
Table 2-3 Localized Resources
Note that the List ResourcesSeveral widgets allow applications to set or read lists of items in the widget. Table 2-4 shows which widgets allow this and the resources they use to set or read these lists. Because the list items may need to be localized, do not hardcode these lists. Rather, they should be set as resources inapp-defaults files, allowing them to be localized. The type for each list is XmStringList .
Table 2-4 Resources Used for Reading Lists TitleTable 2-5 lists the resources used for setting titles and icon names. Normally, an application need only set the*title: and *iconName: resources. The encoding of each is automatically detected for clients doing proper locale management. All of these are of type char or XmString .
Table 2-5 Resources Used for Setting Titles and Icon Names Text WidgetTable 2-6 lists theText[Field] resources that are locale-sensitive or about which the developer of an internationalized application should know.
Table 2-6 Locale-Sensitive Text[Field] Resources Input Method (Keyboards)Table 2-7 lists localized resources for customizing the input method. These resources allow the user or the application to control which input method will be used for the specified locale and which preedit style (if applicable and available) will be used.
Table 2-7 Localized Resources for Input Method Customization Pixmap (Icon) ResourcesTable 2-8 lists pixmap resources. In some cases, a different pixmap may be needed for a given locale.
Table 2-8 Pixmap Resources A pixmap is a screen image that is stored in memory so that it can be recalled and displayed when needed. The desktop has a number of pixmap resources that allow the application to supply pixmaps for backgrounds, borders, shadows, label and button faces, drag icons, and other uses. As with text, some pixmaps may be specific to particular language environments; these pixmaps must be localized.
The desktop maintains caches of pixmaps and images. The
XtResolvePathname() function, the XmGetPixmapByDepth() function substitutes the requested image name for %B. The paths may also include other substitution fields accepted by the XtResolvePathname() function. In particular, the XtResolvePathname() function substitutes the display's language string for %L, and it substitutes the components of the display's language string (in a vendor-dependent way) for %l, %t, and %c. The substitution field %T is always mapped to bitmaps, and %S is always mapped to Null.
Because there is no string-to-pixmap converter supplied by default, pixmaps are generally set by the application at creation time by first retrieving the pixmap with a call to Font ResourcesTable 2-9 lists the localized font resources. AllXmFontList resources are of type XmFontList . In almost all cases, a fontset should be used when specifying a fontlist element. The only exception is when displaying character data that does not appear in the character set of the user (for example, displaying math symbols or dingbats).
Table 2-9 Localized Font Resources Operating System Internationalized FunctionsTable 2-10 lists the base operating system internationalized functions in a common open software environment.Applications should perform proper locale management with the assumption that a locale may have from 1 to 4 bytes per coded character.
Table 2-10 Base Operating System Internationalized Functions
Table 2-10 Base Operating System Internationalized Functions (continued)
|