- Overview of internationalization
- What does internationalization affect?
- Internationalization steps
- Internationalization of the Eclipse Platform (V 1.0)
- Summary and additional reference
- Resources
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
What does internationalization affect?
Monoglots take note
This is the beginning of your sensitivity training. There may be a quiz at end of this article. :-)
Let's begin with a distillation of the list of culturally dependent data presented in the Java Internationalization tutorial (see Resources later in this article), reordered by the likelihood that the typical developer will encounter it, and followed by details on each:
-
Text Messages, labels on GUI components Online help (*.html), Plug-in manifest (plugin.xml)
-
Data formatting Numbers, dates, times, currencies Phone numbers, postal addresses
-
Regional and personal substitutions Measurements Honorifics and personal titles
-
Multimedia considerations
Text
Messages, labels on GUI components
Resource bundles nicely handle language-dependent texts. The strategy is either to load all strings at once into a ResourceBundle subclass, or to retrieve them individually. The Eclipse Java Development Tooling (JDT) in version 2.0 provides wizards to support the detection of translatable strings. We'll return to them shortly in Internationalization steps.
Loading translated strings into memory is only the first step. The next step is to pass them to the appropriate controls for display (such as a label, text field, menu choice, etc.). The page designer and programmer must work together to assure that the chosen layout allows for appropriate resizing and reflowing of the dialog. The layout support in the Standard Widget Toolkit (SWT) library relies heavily on the programmer to "do the right thing" by specifying layout descriptions that react appropriately to changes in field sizes. The article on the eclipse.org Web site "Understanding Layout in SWT" (see Resources) covers the implementation issues in detail.
This is particularly important because text length increases during translation. English phrases are often shorter than their equivalent translations, usually on the order of 40%. Font sizes also may need to be modified to accommodate the local language.
Online help (*.html), Plug-in manifest (plugin.xml)
These forms of text content are more involved than simple key/value-oriented properties files, so the steps to their externalization are slightly more complex.
In the case of the manifest file, it is coupled with a similarly named property file, plugin.properties, containing only the externalized text. Special care must be taken with manifest files like plugin.xml and fragment.xml, since the attributes of the tags can contain both translated and untranslated text. Consider the benign example below:
Listing 1. Plug-in manifest file, before translation
<plugin
name="Java Development Tools UI"
id="org.eclipse.jdt.ui"
version="2.0.0"
provider-name="Object Technology International, Inc."
class="org.eclipse.jdt.internal.ui.JavaPlugin">
Here we see a mix of translatable text, untranslatable text, and "gray area" translatable text, all as tag attributes. Clearly the id and class attributes are not translatable, since they represent programming identifiers. It is equally certain that the name attribute should be translated.
You might be tempted to consider the version attribute (because of the locale-dependent decimal separator) or provider attribute (because of the locale-dependent legal attribution "Inc.") as candidates for translation, since they will be displayed to the end user. However, version numbers are generally left untranslated for two reasons: end users attribute little meaning to their numeric value, and programmers sometimes write code that expects version numbers to be a composed string like "3.5.4". It is arguably a better design decision that the version information be stored as separate numbers like major, minor, and service update to avoid the need to parse a version string, but that discussion is beyond the scope of this article.
The provider-name is left untranslated as well, since "Inc." has legal meaning that defies accurate translation. After identifying what text needs to be externalized, our example now looks like this:
Listing 2. Plug-in manifest file, after translation
<plugin
name="%plugin.name"
id="org.eclipse.jdt.ui"
version="2.0.0"
provider-name="Object Technology International, Inc."
class="org.eclipse.jdt.internal.ui.JavaPlugin">
where plugin.properties contains the externalized string, "Java Development Tools UI" associated with the key plugin.name.
This simple example demonstrates that translating isn't simply providing equivalent words or phrases for your text; it also involves an understanding of the local cultural considerations and potential legal impacts. This is why a translation professional is necessary, as well as translation verification testing.
Data formatting
Numbers, dates, times, currencies
The Java library includes classes that handle the necessary formatting for numbers (decimal separator, thousands separator, grouping), dates (MDY, DMY, first day of work week), times (12- or 24-hour format, separator), and currencies (local symbol, shown as suffix or prefix, leading separator or none).
Phone numbers, postal addresses
These are more subtle and less common text translation concerns, but still noteworthy. Many applications simply allow free-format entry of phone numbers since there are so many local variations. Postal addresses are straightforward: Adding a "State/Province" field and allowing for multiple address lines is generally sufficient.
Regional and personal substitutions
Honorifics and personal titles
Though less common in the United States, the proper enablement of honorifics (Mr., Mrs., Dr.) is considered absolutely necessary elsewhere to avoid a serious breach of etiquette.
Measurements
These are less frequently encountered. This involves substitution of measurement indications with corresponding conversion (for example, miles versus kilometers). In many cases, users will need either simultaneous display of a measure in different units, or an easy way of toggling between them.
Multimedia considerations
In general, products should select regionally neutral sounds, colors, graphics, and icons.
This means no Homer Simpson "D'oh!" sound associated with error messages. If you're thinking that no serious development organization would do such a thing, consider an icon that is typical of those that are proposed and rejected:
The developer wanted to convey a metaphor for "IP router" by using a symbol harkening back to a national highway that traversed the United States from Chicago to Los Angeles, called Route 66. Most Americans would find this metaphor obtuse; imagine the confusion of the hapless non-US user.
Similarly, the image below may be intuitive to many North American users:
But in recognition studies, others from outside the United States have guessed that this is a birdhouse. This is the more universally accepted image for mail:
To avoid confusing and potentially offensive visuals, the best course is to engage professional graphic artists who are aware of cultural issues.