136 e-Business Globalization Solution Design Guide
17.1 Adding new languages
One great advantage of a globalized application over non-globalized applications is that it is
much easier to add new language versions of existing products.
In the case of a non-globalized application, adding a new language version takes less effort
than developing an entirely new product. The new language version must have a new set of
application programming code. This is not just a re-installation. The coding team must modify
all locale-related codes in order that the output conform to the cultural conventions of that
locale. The translation team must thoroughly search throughout the application programming
code to pick out language-dependent data and translate it into the new language.
Locale-related computing and language-dependent data might be embedded with other
codes throughout the program, and a change at one point might affect how the program runs
at others. Due to complex coding and translating processes, errors can easily occur, and
testing and debugging the new language version can also be complicated.
For a globalized application, on the other hand, adding a new language version is much
simpler. The main activity is localization—that is, creating a localized version in the new
language. As discussed in Chapter 11, “Localization” on page 57, adding a new language can
affect two areas—locale-related computing and language-dependent content.
17.1.1 Locale-related computing
In a globalized application, locale-related computing is separated from the core business
logic. In this case, even if there are locale-related codes to add for the new language version,
the core business logic will be unaffected.
Locale-related computing involves codes invoking locale-supporting code libraries such as
ICU and Global Business Object (GBO). Normally, adding a new language version affects
only the GBO by attaching a property file containing the required locale-related information for
the new locale. The code library can then be invoked directly for the new locale.
The majority of locale-related computing in Our Global Travel Shanghai Demo was
implemented by invoking ICU4J, which contains culture-sensitive information and computing
for many locales throughout the world. Therefore, we do not need to add any locale-related
computing to our source code, only to pass the new locale as a parameter to the Locale
Model Bean. The returned value will always conform to the cultural convention of that locale.
For example, if we want Our Global Travel Shanghai Demo to support the Thai language in
the Hotel Search Result page, the room price should be displayed in Thai Barr. By invoking
the relevant ICU4J code with a locale parameter of “th_TH”, we can retrieve the price in the
Thai currency code automatically.
For the GBO-provided name and address format, if Thai must be supported, we only need
add the Format.property file containing the name and address formats used in Thailand.
17.1.2 Language-dependent content
In a globalized application based on the concept of the Single Executable,
language-dependent content has also been separated from source codes and grouped into
an independent resource bundle called the localization pack. To add a new language version
only requires creating a new localization pack in the new language by translation.
To translate this data, the development team need only send the localization pack in the
source language to the new language's translation team. This team translates the data and