Tivoli Service Desk 6.0 Developer's Toolkit Script Programming Guide
As many software developers increase their market scope, inevitably software developed in one country will be sold or used in a different country. This migration requires software developers to be aware of the special requirements that result from the use of software in an international market.
In addition to being aware of the cultural differences that you may have to address in building code, you should also be aware of the effect that localization may have on an application. Altering a software application for a specific cultural group is called localization.
What if you are not aware of the nuances that exist in an international market? How do you create software that can be localized easily?
The most straightforward solution to localization is to store all necessary resources in .df files. That is, all bitmaps, menus, strings, icons, and dialog boxes are compiled and stored separately from the remainder of the code. When an application is sold outside the United States, distributors receive all the necessary tools and instructions required for editing these resources.
Once these resources have been localized appropriately, the files can be rebuilt and copied onto the installation media.
No code needs to be modified, and the installation media does not need to be modified in any other way. The installation program will also be localized as a result of this operation.
Wherever possible, Tivoli applications avoid using proprietary code to handle internationalization issues. Because of this, any operating system's native, wide-character copy process can convert two-byte code to one-byte code.
Internationalization data and API calls made available by the host operating system are always used in lieu of proprietary facilities. This reduces the size of the application and makes the addition of new supported locales simple.
All strings used by Tivoli applications are internally stored as Unicode strings. Unicode (or ISO 10646) is a system of uniform sixteen-bit characters that support the alphabets of all international locales at once.
Many other international applications use the ISO 8859/x standard for international characters strings (also known as multi-byte). This standard uses eight-bit characters for smaller alphabets and sixteen bit characters for larger alphabets. While the application using multibyte code pages may use a little less memory, the resulting performance hit is impractical.
A single ISO string can have a mix of eight- and 16-bit characters. Simple operations like backing up a single character or counting the characters in a string become more complex because there is no way to reliably determine whether a single byte is an entire character or part of a character without looking at a number of the bytes that precede it.
TSD Script's internationalization support makes is easy to write code that conforms to the requirements of the locales that it supports. It is important to remember, however, that cultural biases do exist and that they can affect the perception of an application written in the United States and translated for a specific locale.
You need to be aware of any particular bias that may affect an application used in a different locale. For instance, the color purple has these cultural interpretations:
The following contexts are particularly important to accommodate in international applications:
Operating systems adapt to the alphabet of a local language by using a different code page. A code page is essentially a table of number-to-character associations that allows a character string to be displayed properly.
A computer system displays the letters its code page associates with the numbers in a string. Software must be written so that the appropriate strings are sent to the operating system via the code page.
A single operating system might support multiple code pages that contain many of the same characters. However, a character that is common to both code pages is not required to be associated with the same number on both pages.
For example, the letter e is number 233 in the Latin alphabet code page used by Windows 95. The same letter is number 130 on the Latin alphabet code page used by MS-DOS.
Using the Developer's Toolkit Interface Designer, a translator loads the strings written for one code page and translates them to another. The native operating system determines what code page is available to applications.
Where different code pages are used, there are different keyboard layouts as well. An international application must allow default accelerator mappings to be adjusted to any keyboard.
Different locales can require different sort orders. An application must be written so that the alphabetical order of the local code page provides sorted lists in the desired order.
Case-insensitive string comparison has varied meaning in different locales. In ideographic languages such as Japanese and Chinese, "case sensitivity" has no meaning. In other alphabets, letters might have more than just an upper or lower case.
Once a .df file is created, Developer's Toolkit uses native calls on an operating system for sort and compare strings.
Combining substrings to form complete phrases is a classic mistake made in many initial internationalized versions of an application. Since sentences are constructed differently in other locales, verbs, nouns, adjectives, and adverbs can all appear in different positions with respect to one another. Many languages also assign a gender to various parts of speech, which requires different words to be used depending upon whether the associated noun is male, female, or neuter.
Note: You should avoid combining substrings whenever possible.
Ideographic languages (such as Japanese and Chinese) have too many characters for all of them to be represented on a keyboard. Therefore, most operating systems allow users to enter phonetic spellings of a character using a different alphabet. The operating system then proposes a set of possible ideographs from which the user makes a choice. The selected character is placed in the document or entry field. There can be multiple phonetic alphabets available in one locale.
Developer's Toolkit supports the standard IME supplied by the operating system.
Different locales use different formats for displaying numerical information, dates, times, and monetary sums. For example:
Because 8.5"x11" paper is not used in all locales, an international software
application must allow for different sizes when printing pages and envelopes.
Developer's Toolkit does not have a mechanism to convert paper sizes.
Most locales outside of the United States require applications to display metric rather
than English units.
Developer's Toolkit does not have a mechanism to convert English units to metric units.
After text is translated to a different language, text size can be significantly larger or smaller than the original. (This is also known as translation spread.)
For example: Translating a paragraph from English to Spanish or German increases the overall size of the text by approximately 30%.
The table that follows illustrates this concept.
Number of characters | Text expansion factor |
1 to 10 | 100 to 200% |
11 to 20 | 80 to 100% |
21 to 30 | 60 to 80% |
31 to 50 | 40 to 60% |
51 to 70 | 31 to 40% |
More than 70 | 30% |
Graphical symbols on icons and other bitmaps must either have the ability to be easily changed, or have a universal meaning. International software applications should avoid having text directly in bitmaps that require them to be translated for every locale.
The possibility exists also that symbols that may seem innocent and universal may have an insidious or insulting meaning in specific locales.
The same precautions should be taken with regard to the use of color for dialog boxes and windows. Some locales perceive color quite differently than Western cultures do.
The table that follows illustrates differences between United States and Chinese perceptions of color.
Color | Nation and interpretation |
Red | China: prosperity, rebirth United States: power, stop, danger |
White | China: death, mourning United States: purity, innocence |
Yellow | China: joy, wealth, rank, honor United States: caution, possibility of physical danger |
Software applications use the concept of a locale to identify a cultural group to which an application can be localized.
Language, country, and nationality (culture) are independent entities: every combination of these entities must have a unique locale associated with it. For instance, the citizens of Switzerland speak four different languages:
Each of these combinations requires a separate unique locale.
The following locales are fully supported in TSD Script for Windows, UNIX, and OS/2.
Character sets, as well as other printer characteristics, may now be controlled via an entry in the softart.ini file. The "ControlString" entry in the Printer section of softart.ini contains a sequence of characters that are sent to the printer whenever the PRN or LPT1 file name is opened for writing.
This feature allows you to print strings containing "extended" characters. An extended character is one whose ASCII value is greater than 128. These characters are used by international versions of operating systems to display accented characters or characters not available on a standard U. S. keyboard (such as the German "ss" character).
If you use a Hewlett-Packard laser printer, the control strings "\x1B(9U" for MS-Windows and "\x1B(12U" for OS/2 select the appropriate character set to support the extended characters. If you use a printer from another manufacturer, consult the documentation for the printer to find the appropriate control sequences.
Avoid using "extended" characters in configuration files that are used by Developer's Toolkit (sai_sql.cfg, softart.ini, and so on). An extended character is one whose ASCII value is greater than 128.
The following are assumptions for locales where the native date format is a two-digit year for "year 2000" processing. If the years are between:
To avoid ambiguity about the relevant century, use the Regional Settings Control Panel in Windows to access the International setting where you can select a date format with a four-digit year.
Note: In UNIX, use the locale default.
Tivoli Service Desk 6.0 Developer's Toolkit Script Programming Guide