Guideline A: User interface

A1: Isolating the UI

Isolating the user interface

There should be no need for the translator to change or examine the logic of your product’s executable code in order to search for and identify translatable content. Translation proceeds quite slowly, and sometimes is impossible under these conditions.


Example: The following Java code segment intermixes UI and code, making the translation task extremely difficult:

public class SwingClient extends JApplet implements ActionListener, KeyListener
{ private JLabel nameLabel = new JLabel(“Enter Your Name”);
private JButton joinButton = new JButton(“Join the Chat Room”);
private JButton leaveButton = new JButton(“Leave”);
private String enterPrompt = “Enter Name To Join”;
private String clientName;
:
private void join()
{ clientName = nameTextField.getText();
if (clientName.equals(enterPrompt))
{ nameTextField.setText(enterPrompt);
return;
}
System.out.println(clientName + “is joining.”);
:
}
private void leave()
{ System.out.println(clientName + “is leaving.”);
:
}
}


If UI is intermixed with the code, there is a risk that the translator may mistakenly translate part of the code and keywords, thinking they are UI information. At the completion of the translation, the developer is then obliged to retest all the logic that has been exposed to the translator for every translated version. These extra and costly test cycles can be easily avoided by isolating the UI information. Although machine translation aids such as OpenTM2 can now be used to hide or protect portions of the code from inadvertently being modified by the translator, the need to isolate UI information from executable code still exists.


Guideline A1


Isolate all the User Interface (UI) information from the executable code at the source level and at the load module level.


Isolating the UI information at the source level in a form that is easily understood and edited is the first step in minimizing the cost of translation.

You can achieve isolation in many ways, and the technique used will depend heavily on the system and tools that are used to create and present the messages and dialog boxes. When choosing a particular technique, consider the translation tools that will be used by the translator. In many situations, the translation tools can hide or protect information that should not be translated, and at the same time present the translatable material in final form. The translator can concentrate only on the concepts that are expressed by the source language.

After the UI is translated into other languages, the question arises as to which version is required by the users. In some countries, such as Switzerland, where there is more than one official language, users may need to access several languages. Add to this the need to communicate across borders, and a very strong case is made for a capability that allows the user to dynamically choose the language or languages of communication. If the UI is isolated from the executable code at the load module level, it is possible for the appropriate language version of the UI to be loaded at execution time. A single instance of the application that can be used by many users must respect every user's preferences, one of which is the language of communication.


Example: For the sake of reducing development time, it is very tempting to imbed messages inside the program logic. The following is the Hello World program in Java:


/* This program displays the "Hello World!" message */
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World!");
// Bad: string literal inside the program logic
}
}

To isolate the message from the executable code requires extra work. The following is the same Java program but the translatable text is separated from the core application through the use of the ResourceBundle class.

import java.util.*;
public class RuleA1 extends Rule {
private static final String RESOURCE = "RuleA1";
public String getItRight() {
ResourceBundle bundle =
ResourceBundle.getBundle(RESOURCE, Sample.locale);
return bundle.getString("greeting");
}
public String getResource() {
return RESOURCE;
}
}

RuleA1.properties
// Sample.locale = Locale.US
greeting = Hello World!
RuleA1_de_DE.properties
// Sample.locale = Locale.GERMANY
greeting = Guten label Welt!
RuleA1_ja_JP.properties
// Sample.locale = Locale.JAPAN
greeting = \u3053\u3093\u306b\u3061\u306f\uff01\ …


The different translations of the string, Hello World! are stored in flat text files called property files which are external to the executable code. This allows locale-specific data to be tailored according to the end user’s language and country/region. Only the property files are sent for translation, and the program logic remains unchanged for all languages.


Guideline A1-1


Package UI modules separately from the executable code.


You can link the UI modules to the executable code either by static or dynamic binding, or a combination of both. In static binding, each translated version of the application is created by linking the executable code with the translated UI modules. In dynamic binding, all the translated UI modules are available for the code to select during execution, resulting in one executable module for all the languages.

Static binding usually results in faster execution speed, but at the expense of flexibility and expandability. Suppose there is a need to add a new language or an error is discovered in one of the translated UI files. If dynamic binding was used, all you have to do is ship the new or corrected UI files to your customers, and your application can automatically use the latest UI. If static binding was used, you must rebuild, retest, and then reship every translated version of your application. Furthermore, each customer is restricted to using only the languages that have UI bound to the executable module. A Chinese user, for example, cannot access French UI because you did not incorporate the French UI files into the Chinese version of your application. Static binding may no longer be relevant in IBM software development because different versions of the product for different language translations are no longer produced. Multi-language and multi-culture support is now integrated into a single version of the product.

Application maintenance is simpler for the dynamic binding situation because you have only one source for your application.


Guideline A1-2


Design applications so that they can be easily translated.



For web globalization, separate translatable information such as form field descriptions and error messages from the executable source code.