Customizing applications for languages other than English

In Zim applications, some information that appears in the user interface, such as data masks, and error and processing messages, is language dependent. Zim provides tools to handle these dependencies and to make the application appear to the application user in languages other than English. A single application can be designed to handle several different languages simultaneously.

Language dependencies occur in four major areas of any application:

1. Character handling
   • definition of non-English characters
   • uppercase/lowercase translation
   • collating sequence for sorting, indexing, and comparing

2. Zim errors file
   • errors produced by Zim itself
3. Internal messages and strings
   • errors and processing messages produced for the application’s forms
   • day and month names
4. Data masking
   • numeric masks
   • alphanumeric masks
   • date masks

Tools used for adaptation

Zim provides three tools specifically geared to language adaptation:

• the developer-defined collating table
• the ability to translate error messages
• the ZIMLANG utility to alter masks, day names, and so on

The collating table is stored in the database. The collating table defines, internally to the system, how characters are represented and how they are to be sorted.

You can provide your own collating tables. For applications in languages other than English, the collating table enables you to properly handle special characters, such as accented characters.

Messages, strings, and mask characters can be customized for the desired language by translating the error message file or calling up the ZIMLANG utility.

Restrictions

Although Zim’s language-independence features solve a number of language adaptation problems, keep in mind these restrictions:

• Applications are developed in English
• You must ensure that output from an application is properly translated into the required language(s)

Numeric input/output can be adapted to another language only if it is controlled by a mask or numeric form field. Numeric values input from documents, including the terminal, or output without masks, appear in the original English format.

Zim does not recognize multi-character currency symbols.

Character Handling

Some languages use more characters than the twenty-six found in the English alphabet. These extra characters must be defined to ZIM in the collating table.

Collating Information

Zim uses a collating sequence that the database initialization program ZIMINIT reads from a collating table stored in an operating system file. The name of the collating file is operating system dependent. If the collating table is not found, Zim uses the standard collating sequence for your operating system.

Applications that have a requirement to define a collating sequence other than the standard ASCII collating sequence (i.e. programs that use accented characters) should rename the appropriate collating file in the Zim software directory to ” COLLATE.ZIM”. Renaming the file ensures that it is read by the Database Initialization program. In Zim for Windows, ZCOLLATE.DOS defines a collating sequence for all the OEM-accented characters while ZCOLLATE.WIN provides a collating sequence for the ANSI-accented characters.

The collating file is a text file that can be modified with any text editor that can handle ASCII characters. The file contains one entry per line. Each entry consists of the following information:

• character representation (the internal value that represents the character)
• collating value (the sorting value assigned by to the character by the developer)
• lowercase representation (the lower case equivalent of the character)
• uppercase representation (the upper case equivalent of the character)

Each field in an entry is separated from the next by a space. The characters can be entered as single characters that exist in your hardware’s character set or as a hexadecimal value. Hex values are entered in the format

hh

where hh is a pair of valid hex characters (0 to 9, a to f, A to F).

Entries in the collating table are governed by the following rules:

• A character is known as a letter if either its uppercase representation or lowercase representation differs from the value placed in the character representation field of the collating table.
• A character is upper case if it is a letter and if the character’s uppercase representation (the entry in the “uppercase representation” field) is the same as the character representation.
• Some characters, such as $, #, @ are the same regardless of case. Therefore the entry in either the “uppercase representation” field or the “lowercase representation” field is irrelevant.

Accented Characters

A developer can treat a series of similar characters in the same way. For example, the characters

• á
• â
• Ã
• a

can all be assigned the same collating value. For sorting purposes, à  and á would be treated the same way as a. This situation simplifies the data entry responsibilities of an application user. The user does not have to remember if a customer’s name, for example, contains an accent. On the other hand, record searches become more inefficient by having a wider scope (searches for records that contain a also return records that contain á and a).

The developer must decide if it is better for the application to differentiate between accented characters or to treat all similar characters in the same way. To differentiate accented characters, the developer can assign them collating values that correspond to user-defined locations in the normal collating sequence.

Zim error message translation

Error messages are produced from templates stored in the ZIM errors file. This file is described in Customizing Error Messages.

Error message prefixes ( eg *** Error***) and internally generated form messages can be modified using the ZIMLANG utility.

Using ZIMLANG

When customizing an application for a different language, internal strings (processing messages, day names, and so on) and mask characters must be taken into account. Strings and mask characters are customized through the ZIMLANG utility. For information on the use of the command, see ZIMLANG.

Internal strings

ZIMLANG can be used to modify the following types of strings:

• error message prefixes ( eg *** Error***)
• day and month names
• form error messages
• processing messages

When ZIMLANG is used to translate processing messages, formatting characters (such as / n, / r, / d) must not be changed, as they are the codes used to properly format the display of the messages.

Masks

Masks are used in reports and forms to precisely define how data is to be displayed. ZIMLANG can be used to replace the following mask characters with different characters:

• Date
• day (D)
• month ( M)
• year ( Y)
• numeric
• currency ($)
• comma (,)
• decimal point (.)
• alphanumeric
• various characters (?)

Several rules must be followed when translating mask characters with ZIMLANG:

• The mask characters for day, month, and year must be unique (i.e. the mask for day c
  annot be the same as the mask for month).
• The mask characters for the decimal point, the comma, and the currency symbol must be unique (i.e. the mask for the decimal point cannot be the same as the mask for the comma).
• ZIM developers can specify masks in a report, in the $mask function, and for a form field. Masks are always specified in English (the default format). ZIMLANG affects only how application users see masks in form fields and how they see masked values in form fields, reports, and the $mask function.

In reports and in the $mask function,

• only numeric masks are affected by ZIMLANG
• when a numeric mask indicates the presence of a decimal point, comma, or currency symbol, the newly defined character is used.
• application users never see the masks themselves, just the masked data.

In forms, all three classes of masks (date, numeric and alphanumeric) are altered by ZIMLANG, with the following results:

• In date masks, the new characters for day, month, and year replace the English characters
• In numeric masks, commas and decimal points in displayed values are replaced by the appropriate alternate language characters.
• In alphanumeric masks, mask characters (such as ?) are replaced with an appropriately defined alternate language character.

See Also

$mask

How To Use Data Masks