Foundation1 / Development Guide / Web Client / Considerations / Localization / This page

Preparing Web Client for Translation

This chapter deals with programming guidelines to achieve an easy localization.

Contents

• Achieving Easy Localization
• Programming Guidelines

Achieving Easy Localization

Creating applications that are easy to localize is not an easy task. However, if a few basic rules are followed the task will become possible.

Isolate language dependent information

The most important rule for localization is to never mix functional code with strings, messages, or any other information that has to be modified to localize an application.

Allocate extra space for strings

Many languages are more verbose than English and require more space to hold strings or to display dialog boxes. The following table shows the percentage of additional space that an application should allocate for non-English strings of various lengths.

In the English version of your application, create a layout that leaves room for longer versions of labels and other texts. Although table cells etc. will stretch to fit any length of text, this can cause the layout to become seriously distorted, so it is better to allocate plenty of space from the beginning.

Handling foreign languages

Never make assumptions about language usage when dealing with foreign languages. The ordering 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.

Incorporate graphic objects such as bitmaps, cursors, and icons with these considerations in mind:

• Avoid the use of embedded text in graphics. Text is difficult to modify when in graphical form. If you cannot avoid this, leave enough space for translation and try to create tools to simplify the modification.
•  Look for graphic objects that represent international concepts, because graphic objects are also language dependent.

Keep in mind the following points when planning screen elements:

• Allocate as much space as possible for text containers, such as labels, background texts, radio buttons, push-buttons etc.

Important! All messages should be self-contained, not dynamically assembled. In cases where messages have variables added to them at runtime, do not make any assumptions about the position of the variable in the message.

Programming Guidelines

One of the considerations when developing the IFS/Localization architecture has been that it should have minimum impact on how programs must be written in order to receive native language support.

For web solutions, IFS/Localization is capable of translating textual information in the dynamically generated HTML pages (see JavaScript and Java below ).The script-parts of the pages are translated in run-time by all functions that accept language-dependant texts. The resulting HTML code sent to the client browser will then be completely translated.

Java pages

In the Java code there are some functions that are capable of performing runtime translation (for example ASPField.setLabel). When using such a function you must specify the text argument so that it starts with a localization identifier. A localization identifier is a series of upper-case alphanumeric characters followed by a colon and a space.

field.setLabel("DEMORWEMPLOYEMP_NO: Employee Number")

Similarly, in pages with manually written HTML sections, all language-dependent texts should be written using the functions of the ASPHTMLFormatter class and should start with the localization identifier. For example, if fmt is an instance of the ASPHTMLFormatter class, a text label should be written as:

fmt.drawWriteLabel("DEMORWEMPLOYEVNT_RPT: Event Report")

The localization identifier must be unique within the whole application, and may be no longer than 100 characters. The identifier should start with the complete name of the package structure of the class plus the class name itself. If you wish to force multiple texts in your page to have the same translation you should use the same localization identifier for the texts. IFS/Localization tool will use the text of the last occurrence of a localization identifier as the prog text when translating.