test

Solaris Internationalization Guide For Developers

Chapter 8 Desktop Environments

The Common Desktop Environment (CDE) is the standard GUI desktop interface for Solaris 7. Not only is it the user's main interface to the system, 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

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 only has to be localized to match the target language and customs.

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

It is important that each layer within the desktop use the proper internationalization interface standards which are described in the following sources:

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.

Xtprograms 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 may 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 may 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 Solaris Common Desktop Environment: Programmer's Guide, Chapter 2 "Integrating Fonts," and also the CDE man pages DtStdInterfaceFontNames(5) and DtStdAppFontNames(5) for additional information.

Input Methods

CDE provides the ability to enter localized input for an internationalized application that is using Xm Toolkit. The XmText[Field] widgets are enabled to interface with input methods from each locale. Input methods are internationalized because some languages write their text from right-to-left, top-to-bottom, and so forth. Within the same application, you can use several fonts that use different input methods.

The pre-edit area displays the string that is being pre-edited. This can be done in four modes: OffTheSpot, OverTheSpot (default), Root, and None. In OffTheSpot mode, the location is just below the MainWindow area at the right of the status area. In OverTheSpot mode, the pre-edit area is at the cursor point. In Root mode, the pre-edit and status areas are separate from the client's window.

Internationalization and CDE

Multiple environments may 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 and China.

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. It will contain 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 may 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 a tool should also be developed 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 covers the exchange of information between applications on different hosts. The transfer of data has to 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 may apply. The conversion depends on the specific protocol. If the protocol allows 8-bit data, the protocol will need to specify which side does 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.

Due to the fact that 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. There is also the ability for dtmail to have characters of different encodings within the same mail, for example, SJIS and EUC encodings for the Japanese (ja) locale.

OpenWindows

Solaris 7 does not have any changes in OpenWindows with regard to internationalization. Applications that were developed for previous versions of Solaris will run in Solaris 7 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.

For information on international OLIT, see the internationalization chapter of the OLIT Reference Manual.