Sun Software Product Internationalization Taxonomy

Print-friendly Version

Chapter 1 Introduction

This document defines what it means for a software product to be internationalized. It is intended for:

• Software designers - To evaluate internationalization areas as they pertain to their product designs



• Product review committee members - To determine if a product complies with internationalization policy



• Engineers - To understand internationalization considerations in implementing a product design



• Engineering managers - To aid in determining the product road map for resource planning



• Software quality engineers - To define test plans and create tests that verify adequate internationalization



• Technical product reviewers - To aid in evaluating the internationalization status of a product

The benefit behind defining internationalization is having a common understanding of the term "internationalized", which helps to communicate product information throughout the company. A further benefit is better integration and interoperability of products. Customers will see consistent functionality from one product to another, and will buy additional products with the confidence that new products will handle their data in the same manner as those they already use. This document does not describe how to internationalize a product. While there are some coding examples given to illustrate the concepts described in the text, they are not intended as a guide to implementation. Please see the "References" section for further reading.

This document describes the Internationalization Assessment Matrix. The matrix is an overview of internationalization in different areas of a software product. The columns in the matrix represent different types of interfaces that a product can provide for users or other software products. The rows represent different objects and areas of functionality that a software product might offer. The matrix lets you quickly determine which areas are relevant to your product and which ones are not.

Begin by reading Chapters 1-3 of this document to gain an understanding of the terminology. Then examine the matrix along with the related descriptions in Chapter 4. The "Descriptions" and "Requirements for Compliance" sections are structured to correspond to the boxes in the matrix. Determine the relevant cells for your product, and address the requirements for these cells.

A familiarity with key terms is necessary for understanding the rest of this document.

Internationalization (I18n)

The word internationalization is sometimes abbreviated as i18n, because there are 18 letters between the i and the n. There are several definitions of internationalization in books and on Web sites. In this document, internationalization is making program code generic and flexible so that specifications from markets around the world can be easily accommodated. Part of internationalization is making the product localizable, that is, enabling the interface to be translated with a minimal impact on the program code.

For example, instead of hard-coding message text, as in:

/* This is not internationalized code */
printf("This message needs internationalization.");

the message is externalized into a message catalog, using catgets():

/* This is internationalized code */
printf(catgets(mycatalog, 1, 1, "This message is now internationalized."));

Another important part of internationalization is allowing the data processing to handle characters and data formats from all over the world.

For example, instead of assuming a sort by byte value, as in this C fragment:

/* This is not internationalized code, since strcmp() compares byte
   values, producing an invalid sort order */

if (strcmp((const char *)string[q], (const char *)string[p]) > 0)
   {
     temp = string[q];
     string[q] = string[p];
     string[p] = temp;
   }
 

The strings are sorted by locale conventions using a locale-sensitive function:

/* This is internationalized code, since strcoll() uses locale
   information to determine sort order */

if (strcoll((const char *)string[q], (const char *)string[p]) > 0)
   {
     temp = string[q];
     string[q] = string[p];
     string[p] = temp;
   }

Internationalization comes in several variants:

• Monolingual internationalization - Enables the creation of localized versions of a product, where each localized version supports only its target locale. This is no longer sufficient for business requirements.



• Internationalization for multilocalization - Supports localization and data processing for multiple locales, where the actual locale is selected on execution of the product or at runtime.



• Multilingualization - Enables data processing and display in multiple languages and locales simultaneously, for example, mixing Chinese and Arabic text in a single document.

Internationalization for multilocalization is the minimal requirement, but many products should be designed to be fully multilingual. Server software in particular needs to be able to handle user requests in different languages and with different cultural conventions simultaneously.

Localization (L10n)

Sometimes you will see localization abbreviated as l10n, because there are 10 letters between the l and the n. Localization is the process of customizing a product for a particular locale. This can involve several different types of customization, including:

Translation of the user interface and documentation into a different language.

Altering some format fields in resource files according to the locale conventions, for example, changing a date format from mm/dd/yy to yy/mm/dd.

Adding code modules that implement locale-specific functionality, such as an input method editor for Japanese or a module that calculates Hebrew calendar dates.

Not all internationalized products are localized. This document is concerned with localization only to the extent that it defines requirements for internationalization.

Locale

A locale is a specific geographical, political, or cultural region. It is usually identified by a combination of language and country, for example, en_US represents the locale US English. In some cases, a language identifier alone is sufficient.

Providers and Consumers

This document divides software functions into two groups: providers and consumers. A software product usually has both provider and consumer functionality, depending on the product area; therefore, each combination of an interface and an object in the matrix has a provider and a consumer.

A provider provides internationalization functionality. For example, an input method is a provider of internationalized input functionality for an application programming interface (API). It contains calls and parameters that a consumer can use to retrieve data typed in by the user, or to display the input method editor window. For example, to ensure that international data is handled correctly, a consumer uses parameters, such as character set name and locale in a provider application protocol.