International Language Environments Guide

Chapter 6 Desktop Environments

The Common Desktop Environment (CDE) is the standard GUI desktop interface for Solaris 8. Not only is it the user's main interface to the system, but it is also the interface in which many of the user's locale settings are apparent. The German user sees a German interface; the French user sees a French interface.

The Common Desktop Environment: Internationalization Programmer's Guide provides information for internationalizing the desktop to enable applications to support various languages and cultural conventions in a consistent user interface.

Overview of CDE

CDE is fully internationalized so that any application can run using any locale that has been installed in the system. By keeping the language- and culture-dependent information separate from the application source code, the application does not need to be rewritten or recompiled to be marketed in different countries. Instead, the external information needs to be localized only to match the target language and customs.

The application interface has been standardized to allow functionality in any locale, including East Asia. Solaris 8 complies with the Portable Operating Systems Interface for Computer Environments (POSIX and X/Open specifications, which are also referred to as XPG4.2).

Each layer within the desktop must use the proper internationalization interface standards, which are described in the following sources:

Setting Locales

Most single-display clients operate in a single locale. This is set with the environment variable, usually $LANG or a set of LC_ environment variables, including $LC_CTYPE.

The LC_CTYPE category of the locale is used by the environment to identify the locale-specific features used at runtime. The fonts and input methods are determined by the LC_CTYPE category.

Xt programs that are enabled for internationalization are expected to call the XtSetLanguageProc() function (which calls setlocale() by default) to set the locale.

Integrating Fonts

Your application might be used by someone sitting at an X terminal or by someone at a remote workstation across a network. In these situations, the fonts available to the user's X display from the X window server might be different than your application's defaults, and some fonts might not be available.

The standard interface font names defined by CDE are guaranteed to be available on all CDE-compliant systems. These names do not specify actual fonts. Instead, they are aliases that each system vendor maps to its best available fonts. If you use only these font names in your application, you can be sure of getting the closest matching font on any CDE-compliant system.

See Common Desktop Environment: Programmer's Overview "Standard Font Names" in Common Desktop Environment: Programmer's Overview and also the CDE man pages DtStdInterfaceFontNames(5) and DtStdAppFontNames(5) for additional information.

Internationalization and CDE

Multiple environments can exist within a common open system to support various languages. Each of these is called a locale. A locale specifies the language, fonts, and customs to display data. CDE is fully internationalized so that any application can run in any locale. Any application should be code-set-independent and include support for any multibyte codeset.

All components are shipped as a single, worldwide executable. These support the U.S.A., Europe (Western and Eastern), Japan, Korea, Taiwan, Thailand, China, and the Middle East.

Matching Fonts to Character Sets

Various sets of fonts are used to render a locale's characters. The specific font character set depends on the locale. This information should be in a locale-specific app-defaults file that contains font sets, fonts, and font lists.

XmFontSet specifies the locale-dependent fonts. The resource name is *fontSet. Fonts should not be specifically named. The resource name for XFontStruct is *font. Font lists contain lists of fonts and font sets. XFontList specifies the fonts.

Storage of Localized Text

Text strings in each language should be stored outside of the application and in directories that are identified by locale names. These strings are stored in three types of files: resource files, message catalogs, and private files.

Resource files and message catalogs are both files that deliver text strings. Resource files are compiled when they are loaded and message catalogs are precompiled and ready to be accessed. Any application should be codeset-independent and include support for any multibyte codeset. Private files can be databases of information that include some text strings. Ideally, text strings should be in resource files or message catalogs. If text strings are supplied in a private file, then you should develop a tool to extract and replace text strings.

Xlib Dependencies

X locale supports one or more of the locales defined by the host environment. Direct XlibTM conforms to the American National Standards Institute (ANSI) C library and the locale announcement method is the setlocale() function. This function configures the locale operation of both the host C library and Xlib. The operation of Xlib is governed by the LC_CTYPE category; this is called the current locale. The XSupportsLocale() function is used to determine whether the current locale is supported by X.

Message Guidelines

Message guidelines should be developed and used to create a consistent format and style for text. Use clear and simple English so that all users, including those whose command of English is minimal, can understand every message. The book Common Desktop Environment: Internationalization Programmer's Guide ends with a number of guidelines for producing clear, concise, translatable messages. Messages should explain the problem and suggest how to perform the action successfully. Comments to the translators should also be included that explain concepts, variables, and so forth. The book includes several lists of suggestions for the format style of the message catalogs and the style of the messages themselves.

Before sending out the message catalogs to be translated, it is useful to have the message catalogs translated from English into international English, that is, into a simplified English that can be easily translated into other languages. This speeds up the translation process, reduces the translator queries, and saves costs.

Internationalization and Distributed Networks

This section of the book explains the exchange of information between applications on different hosts. To transfer data, you must consider several parameters:

If the remote host uses the same codeset as the local host, and, if the protocol allows 8-bit data, no conversion is needed. If the protocol allows only 7-bit data, the 8-bit code points must be mapped onto 7-bit ASCII values. There are various strategies for conversion.

If the remote host's codeset is different from that of the local host, the following two cases might apply. The conversion depends on the specific protocol. If the protocol allows 8-bit data, the protocol must specify which side makes the conversion. If the protocol allows only 7-bit data, a 7-bit interchange encoding is needed along with an identifying character repertoire.

Mail Interchange

With the increased use of the Internet and the ease of communicating with people around the world, an email message can be viewed on many platforms and dozens of locales. Standards for email interchange, however, are restricted by desktop machines for which the default email standard is Simple Mail Transfer Protocol (SMTP), which supports only 7-bit transmission channels.

The sending agent converts the body of the message into a standard format and labels it as body. The receiving agent looks at the body and, if it supports the character encoding, converts the body into the local character set.

Because dtmail now uses the Language Conversion Library (LCL), dtmail has the capacity to support multibyte characters in both the subject line, the mail body, and in attachments. dtmail also has the ability to use characters of different encodings within the same mail, for example, SJIS and EUC encodings for the Japanese (ja) locale.

OpenWindows

Solaris 8 does not have any changes in OpenWindows with regard to internationalization. Applications that were developed for previous versions of Solaris will run in Solaris 8 without any changes.

The XView toolkit is not codeset independent. Applications that use the XView toolkit are not supported in non-EUC locales, such as ja_JP.PCK, en_US.UTF-8, or ko.UTF-8.

For information on international XView, see the internationalization portions of the XView Developer's Notes.