Sun Software Product Internationalization Taxonomy

Print-friendly Version

4.1.2.2 Messages

Description

Messages are textual objects. Unlike fixed textual objects (see section 4.1.2.1), they are also translatable components. Messages can appear in the following forms:

Graphical user interface (GUI) components

Character interface components

Error messages

Status messages

Applications are both providers and consumers of messages. Prior to localization, applications use message catalogs, resource files, and configuration files to provide the original language version of messages. Localization centers provide different language versions of these messages. Applications use internationalization features to consume the messages at runtime. Which messages are consumed depends on the locale or language preference of the user.

Some applications or modules can consume messages from, or provide messages to, other applications or calling modules. For example, if a library application is used in conjunction with a database, the library product can pass some database messages on to the user. The library software is then a consumer of the database messages. This type of message consumption must be carefully architected to ensure that the message is in the correct language by the time it gets to the user. The database messages must be available in all the languages that the library product is translated into. The library code must pass the user language to the database so that it can return the message in the appropriate language. This can be very difficult to manage.

Command Line Interface

Messages are typically not used for options in command line interfaces; however, error or help information associated with command line interfaces can consist of messages. For example:

# grep -k
grep: illegal option -- k
--------------------    -
       |                |
 (Error message)  (Fixed text)

Usage: grep -hblcnsviw pattern file ...
-----------------------------------------
                 |
           (Help message)

Character Interface

Messages are used in character interface components. These include menu items, labels, field names, headers, help systems, and error and status messages.

Graphical Interface

Messages appear in GUIs as menu items, labels, buttons, dialog boxes, help systems, and error and status messages.

One key point to remember about messages in graphical or character based user interface components, is that when they are translated they often affect the layout of the interface. For example, problems such as misalignment of interface components or truncation of text can occur. The reason for this, is that the majority of applications are first developed in English speaking countries and then translated into other languages. The translations are usually longer than the original English text. If the application is unable to deal with the extra space required by the translated text, the user interface becomes unusable. The following table provides recommended allowances for expansion based on text length in English.¹

NOTE: The table refers to the number of characters in a message. The expansion required assumes two bytes per character for multi-byte languages, for example, Japanese. On the screen, Asian languages can expand vertically, in addition to requiring more byte storage.

Table 4-4. Recommended Allowances for Text Expansion in Messages

Length of English Text	Expansion Required1
Up to 10 characters	101 - 200 percent
11 - 20 characters	81 - 100 percent
21 - 30 characters	61 - 80 percent
31-50 characters	31 - 40 percent
50-70 characters	31 - 40 percent
Over 70 characters	30 percent

1. Uren, Emmanuel, Robert Howard, and Tiziana Perinott, Software Internationalization and Localization: An Introduction, Van Nostrand Reinhold, June 1993.

Application Protocols

Messages can be used in interprocess communication. An example of this, is the passing of a window title and icon name from a client application to a window manager on X using the Interclient Communications Conventions (ICCC). Both the window title and icon name are messages and reside in an X resource file. Since ICCC uses compound text for interchange, the window title and icon title messages can be translated into localized text. In this example, there is an interesting provider/consumer relationship. The window manager, that is, the consumer, is enhanced so that it always converts the client title and icon name passed from the client's encoding to the encoding of the current locale. In this case, the client is the provider. An XmString is created using the XmFONTLIST_DEFAULT_TAG identifier. Thus, the client title and icon name are always drawn using the window manager's default font list entry.

Storage and Interchange

Storage

Messages can be stored in different file formats and file encodings. They can also be shipped in either of the following formats:

Human-readable format - For example, X resource files or proprietary file formats

Binary format - Created from human-readable files, for example, Java resource bundles or XPG4 message catalogs

The file formats are many and varied, but all fall into the following categories:

Plain text file with little or no formatting information, sometimes known as a "flat text" file.

Plain text file with formatting information, for example, HTML and XML.

Binary file, which is separate from the main executable, and usually language or product dependent, for example, Java resource bundle, XPG4 message catalog, and Microsoft Windows resource files.

Executable with messages embedded.

Messages must be stored external to the main source code to allow for localisation. The storage format is product, language, or technology dependent. Tools or mechanisms for extracting text automatically from source code and storing it in a particular format are available on various platforms. If a suitable tool cannot be found, scripts or simple programs can be written to handle the extraction.

Interchange

It is important that messages or textual objects do not get corrupted during interchange between one application or process and another. An example which highlights internationalization issues with messages in interchange, is the issue of charset conversion in mail systems. When a provider (sending mail system) sends email to a consumer (receiving mail system), information relating to charset is passed using standard MIME headers (see RFC 2045). The receiving mail system uses charset conversion routines to convert the text in the message body to a charset appropriate for its system or locale. Thus, when developing mail systems, you must ensure the integrity of your mail content--text, in this case--by first tagging all outgoing email appropriately and converting all incoming mails to the appropriate target charset.

Application Programming Interfaces (APIs)

Application programming interfaces can be used to access localized messages, that is, translated versions of original text. These messages need to be accessed by applications at runtime to ensure that the correct locale-specific messages are used. Special APIs must be used to retrieve this text. For example, there are two distinct APIs for message handling on Solaris: the catgets() family, which is used with .msg files, and the gettext() family used with .po files. In Java, resource bundles can be used. These are basically Java classes; that is .java files. The API getString() is used to retrieve localized text from the resource bundles.

NOTE: In this case, the provider is the operating system, and the consumer is the software with the messages.

Requirements for Compliance

Command Line Interface

Providers must accommodate messages in all supported charsets, and be able to supply a locale-specific message.

Consumers must understand and specify the current locale and externalize the command text.

Character Interface

Providers must supply a message externalization and retrieval mechanism and accommodate text in the supported charsets. Provider tools should allow for dynamic or utility based resizing of components.

Consumers must externalize translatable messages and accommodate layout changes as a result of text expansion, using available provider tools. They must retrieve messages according to locale.

Graphical Interface

The requirements that apply to character interfaces also apply here for both providers and consumers. The following requirements also apply:

Providers must enable text and graphical elements to be separated.

Consumers must use provider functions to ensure that message text is stored separately from graphics.

Application Protocols

Providers must accommodate messages in all supported charsets and allow for descriptive charset and locale information.

Consumers must supply relevant charset and locale information along with the message.

Storage and Interchange

Providers must supply a storage mechanism that allows messages to be stored separately from code. Interchange must be available for data in all supported charsets.

Consumers must store messages separately from code and provide relevant charset and locale information for proper interchange.

Application Programming Interfaces

Providers must ensure that APIs are available for locale-specific message storage and retrieval.

Consumers must use these APIs to access localized text.