Sun Software Product Internationalization Taxonomy

Print-friendly Version

Chapter 6 Reading the Matrix

The matrix is technically oriented and can seem daunting to people who are not involved in technical product development. This chapter is intended for people who need to read completed matrices and determine product status. This includes people making sales and localization decisions, high level managers, product marketers, and others in similar positions.

This chapter is not intended as a shortcut to filling out the matrix. To understand the fields in the matrix, you must read the appropriate section.

Status entries in the completed matrices should be color-coded. This is to aid in determining overall product status at a glance. The following legend should be at the top the completed matrix:

• Compliant - Product fulfills all the requirements defined for this interface/object combination.
• Partially compliant - Product fulfills some of the requirements defined for this interface/object combination. An accompanying explanation in text form should appear after the matrix.
• Non-compliant - Product does not fulfill any of the requirements defined for this interface/object combination. Plans for future inclusion should be provided in a roadmap.
• Not applicable - Product does not provide the functionality of this interface/object combination.

A fully internationalized product has a black and green matrix. In the majority of cases, purple is interspersed throughout. To determine the severity, see "Explanations for Partially Compliant Areas and Notes" at the bottom of the matrix. If there are several red entries, the product requires a lot of internationalization (i18n) work.

The following categories are displayed across the top of the matrix:

• User Interfaces - Covers the product areas that are displayed to the user and that involve user interaction. This includes all textual and non-textual elements, such as dialog boxes, error messages, and command line help.



• Program Interfaces - Although program interfaces are buried within the code and are not directly visible to users, they support user-visible components by passing data correctly, providing appropriate headers and labels and converting formats.

The following categories are displayed down the left side of the matrix:

• Translatable product components - Describes product items that you can translate into another human language. I18n is clearly visible as these items can be translated or localized.



• Cultural formatting and processing - Describes product items that have different formats in different cultures. This differs from localization in that the formatting occurs based on user locale and not localization. For example, in the U.S., dates are displayed in month/day/year format. In the U.K., dates are displayed in day/month/year. The English product may be used in both regions, but the date format needs to change. Product functionality may also require i18n, depending on what the product does.



• Text foundation and writing systems - Describes text handling. This mainly involves a programmatically controlled area and focuses on the i18n of functionality that relates to text processing.

To understand the matrix, it is best to know what the product is used for and who is likely to use it. Define what sort of data the product receives as input and what it is expected to do to this data. With this information in mind, examine the matrix. The following scenario illustrates how you might use the matrix to check your product's i18n requirements.

Scenario: I18n Verification

Susan Smith, a globalization director, is trying to determine what countries to sell an email server in, and what languages to localize the interface into. She has received this matrix (open this sample matrix in a new window for side by side viewing).

She examines the Translatable Product Components category row by row:

• Translation Negotiations, Defaults and Selection - This row describes the process of determining what language to serve to the user. Since Susan is concerned about localizing the product, she notes that several interfaces are only partially compliant. Reading notes 1, 6, 7, and 8, she finds that:
  
  
  • Language selection for the Manager Console may need to be well-documented for the customer
  • It is unknown whether the Administrator will handle translations, since there is no i18n information on the central product
  • Command line is unlikely to handle localized messages very well
  • Login messages may not be translatable
  • Logs must be in English
  
  
• Fixed Textual Objects - In this row, the issue is whether translation will break the functionality; fixed text is untranslatable text, such as keywords. The fact that there are two partially compliant boxes suggests that the translators may need additional notes to avoid translating text which is fixed, or the translated product may require several cycles of testing, fixing, and rebuilding to make sure that functionality has not been affected by the translation.



• Messages - This row represents translatable text. There are three notes, 9-11, which basically state that the log messages are not translatable.



• Help Systems and Documentation - Help and documentation may be complex to translate and there is a chance that help may not work in some languages; this is described in the next row.



• Icons, Images and Colors - The icons and other images are not culturally suitable, or they may contain lots of imbedded text. Someone will need to review them to determine whether they are appropriate for any international markets and how much work would be involved in creating new icons.



• GUI objects - These objects are compliant, which means all the screens have flexible components.
  
  
• Sounds - Not applicable.



• Other - Not applicable.

Susan then moves on to the Cultural Formatting and Processing category. In the Culture Negotiations, Defaults, and Selection row, Susan is interested in the ability of the program to determine the locale of the user. Note 2 suggests that the locale may only be communicated in a localized product, at least for Manager Console users. Note 18 is not a concern for her, since Admin CLI is server admin.

The next eight rows, sections 2.2.1 through 2.4.2, are concerned with handling and formatting data according to the user locale. Looking at the Time, Date and Calendar row, she sees that the command line cannot handle locale-specific formats, and that the GUI is only partially compliant. Sorting is not handled according to locale in some cases, and the storage of personal names may not handle different name formats. There is a problem in the GUI where postal codes which precede the city or region cannot be accommodated. Searching is not consistent throughout the product.

Finally, Susan examines the Text (Writing System) Foundation category. All user text must be in a character encoding of some kind. In order to correctly parse the data, the program needs to know the character encoding or charset. From this row, she realizes that the command line cannot determine the charset; at a minimum the expected charset should be documented. It also looks like text input using the Manager Console is at risk.

She is pleased with the character handling; the partially compliant notes discuss the limitations of an existing standard, and the need for the addition of a few converters.

Strings are completely taken care of, as are the transfer encodings. This means that words and phrases are processed and stored correctly without corruption, and 8-bit data can pass through the system without a problem.

Device input has a minor issue, an unknown functionality with input method editors (IME). IMEs are used for typing complex writing systems, such as Japanese. It looks like this will have to be tested to verify consistency.

Device output has no problems, so Susan knows that text will display on the screen properly. Now it is time for her to take this information and compare it to the data she has on the international markets. She must determine whether it will be cost effective for her to launch a campaign for the English product in some places and localize the product for others.

It is important to remember that no two products are alike, and the importance of any square in the matrix is relative to the product itself. Sales and localization decisions must be based on individual product features and i18n support for each feature. However, there are several boxes in the matrix, which if marked non-compliant, could indicate serious limitations for international customers. This section identifies areas that require careful consideration:

• 1.1 Translation negotiations, defaults and selection - From a localization perspective, this section is key if the product is expected to handle several translations as part of a single installation. If the user's preferred language is not determined by the program, it cannot display the correct language interface.



• 1.2.2 Messages - This section is even more critical for localization. If messages are non-compliant, they are not localizable.



• 1.3.2 GUI objects - If this section is non-compliant, translations might be unreadable.



• 2.1 Culture negotiations, defaults, and selection - If this section is non-compliant, then it is impossible to deliver data that is formatted in a culturally appropriate manner. This means that dates, numbers, currency figures, addresses, sorting, and similar objects cannot be processed or displayed in a format expected by users in different countries around the world.



• 2.2.1 Time, date, and calendar - A calendar program is of no use if it cannot display the regional calendar and date formats that apply to the user's locale.



• 2.3.3 Addresses - If the product is an address book, for example, and this section is non-compliant, there is no point in selling the product outside the region for which it is designed.



• 3.1 Writing system negotiations, defaults and selection - If the program cannot determine what writing system the data is in, it cannot parse it correctly. This may not be critical if the product only accepts limited data as input, for example, a calculator program which recognizes 0-9 and a few simple mathematical symbols. Most products, however, handle text of some kind and so non-compliance can block international distribution.



• 3.2.1 Characters (semantics and codespaces) and 3.2.2 Strings - These sections are critical for text processing. If either of them are non-compliant, the result may be corrupted data.