Prepare for Localization

Creating applications that are easy to localize, i.e. translate into different languages is not an easy task. This section addresses the rules that should be followed to achieve easy localization. 

Contents

• Basic rules
• Programming rules

Basic rules

Always follow the following basic rules.

• Never make assumptions about language usage when dealing with foreign languages. The order of words can be different, and the number of words required is often greater than in English.

Keep in mind the following grammatical points when preparing an application for localizing:

• Avoid using the same word in more than one message. Some words, such as none, can have different translations (different gender and number) depending on the context.
• Do not create plurals of words by adding s. Keep two strings, one for the singular and one for the plural.
• Avoid using slang, abbreviations, or jargon, because they are difficult to translate.
• Avoid parsing text to obtain information. Parsing normally assumes specific syntax.
• Do not create a long string from several short strings. The long string may not make sense in another language, because the order of parts of speech varies in different languages.
• Do not hard-code the font name, size or enhancement for any object, as these settings may need changing for e.g. double byte languages like Japanese.

All messages should be self-contained, not dynamically assembled. In cases where messages have variables added to them at run time, do not make any assumptions about the position of the variable in the message. Applications should use the services in Error_SYS or Language_SYS.Translate_Constant to show messages that have variables. Each of these services can take up to three variables.

Programming rules

The programming rules in the server environment to support fully translation are listed below.

• When defining error, info or warning messages in the calls to system services Error_SYS and Client_SYS, the tag named 'Message Key' should not be longer than 20 characters.
• It is possible to break a long message into several lines using the concatenation characters in PL/SQL (see example).
• When defining aggregated associations in Rational Rose leading to IID-implementations, each text should not be longer than 20 characters.

Example

Error_SYS.Appl_General('DemoInvoice','NOTPAYED: The invoice :P1 ' ||
                       'is not paid.', newrec_.invoice_no_);

Client_SYS.Add_Warning('DemoInvoice', 'REMOVEINV: Are you sure '||
	               'you want to remove invoice :P1 ?', inv_no_);

Client_SYS.Add_Info('DemoInvoice', 'REM: The invoice is removed.');