Globalization tools and processes in the HP Component Monitoring System

Hewlett-Packard Journal, Oct, 1991 by Gerhard Tivig

Software design and localization are decoupled. All languages are treated in the same way. A database contains the text strings for all languages, and automated tools aid the translator.

The HP Component Monitoring System is an international product designed for a worldwide market. Among the requirements for the product were introduction Of localized versions simultaneously with the shipment of the standard product, full Asian language support, and low incremental effort for localization in any new language.

At first release, the product was localized in the following languages: English, German, French, Dutch, Swedish, Italian, and Spanish. A Kardi/Kana prototype version was available as well. The current release is also localized in Danish, traditional Chinese, and simplified Chinese.

Localization Goals

To fulfill the requirements, a number of goals were set forth very clearly in the design phase of the Component Monitoring System software. The major goals were the decentralization of localization efforts, the automation of the localization process, and the standardization of interfaces.

Decentralization. Decoupling the software design and implementation process (R&D responsibility) from the localization process (technical marketing responsibility) makes it possible to produce a localized Component Monitoring System without interrupting the software engineers working on their software modules. The coordination and timing of the translations are not directly coupled with the software development process.

Automation. Automated processes to generate localized Component Monitoring System software allow efficient generation of localized versions whenever they are needed, especially in prerelease phases (regulatory approval, clinical trials, demonstrations, etc.). The automated processes transform all Component Monitoring System text strings from plain English to the equivalent hexadecimal character representation. Automatic format checking is part of this process. Translation of all text strings of a Component Monitoring System software release in a single pass improves the consistency of the translated text-similar terms are translated the same way in various places. The same translator is responsible for text strings and for the Operating Guide translation.

Standardization. A well-structured native language support (NLS) database is needed. The generation process for localized software and the translation process are the clients of this database. The NLS database is part of the Component Monitoring System software maintenance system.

Simple and standardized interfaces between the components of the localization process are necessary. This includes common file formats for the NLS database, common tools for accessing and handling text strings, and common tools and processes to translate and generate localized software.

Design Decisions

Specific design decisions had to be made to achieve these goals. Among these are:

* The HP standard Roman8 character set is supported. This allows localization of up to 14 Western European languages with one Roman8 character generator, which is located on the display controller function card. This considerably simplifies the handling of European language options.

* All character codes are two-byte codes. Thus all text strings use two-byte character codes. This allows support of Asian languages as well as all European languages in a consistent way. For Roman8 characters, the upper (unused) byte is cleared.

* A given text string has a fixed field length across all languages. Thus the field length of a given text string is not language dependent and the access of a software module to its text strings is language independent. In addition, an text strings are terminated with an end-of-string character. There is no language dependency in the way strings are handled in different languages.

* Text strings are separated from module code. All software modules are language independent. Inside each software module, all text strings are located in TEXT directories, thus being separated from the code (PROG) directory. Changing text strings from one language to another does not affect the Component Monitoring System code. No recompilation of the software is necessary when a new localized Component Monitoring System version is produced.

* Standard HP16 codes for all Asian languages are supported. This allows the Component Monitoring System to handle all Asian languages identically and supports the connection of Asian printers as well. For each Asian language, a specific Asian EPROM card with the complete font set is supported.

* The standard character cell supports all Asian language fonts. The standard character cell is 16 pixels wide by 20 pixels high. The Asian fonts (Kardi/Kana, Chinese) are handled as right-justified 15-by-16-pixel characters (see Fig. 1).

A pixel is 0.219 nun wide by 0.352 nun high, giving an aspect ratio of 1.6. An Asian character should have a square appearance, so the display controller firmware doubles each pixel in the x dimension. This means that a Kanji character takes twice as much space in a horizontal string as a Roman8 character. Since each Kanji character occupies two normal character cells, all Asian strings are limited to half the length of Roman8 character strings. The Asian translation tool takes this restriction into consideration. Mg. 2 shows the traditional Chinese translation of a typical Component Monitoring System task window.