Q: Once I have ICU, do I have to completely internationalize my program?
A: No, you don't. You may only need a subset of the features, and only certain aspects of
your program may need to be internationalized. Suppose that you have a server program that
is using an XML parser, like XML4C. Your internationalization might be limited to sorting
certain fields within XML data based on the country or language. Even if your program does
not use Unicode internally, you still often need to translate into and out of multiple
character sets.
Q: But suppose that I do want a "checklist" of items to watch for?
A: The basic steps to internationalize software using the ICU are described below.
- Translate Strings: The first step to take in preparing your program is to
enable translation of display strings (strings that get displayed to the user on the
client side) by separating them from the rest of your code. In the ICU the resource
bundles provide a general mechanism that allows you to access strings and other objects
according to locale conventions.
- Remove Concatenation: The ordering of parts of a sentence is different in
different languages; this difference can easily lead you into trouble. For example, if you
create a string by concatenating "File deleted on " with the date, the localizer
is limited to modifying only the string, and not the position of the date. If a language
requires verbs to be at the end of the sentence, the localizer is stuck. You can replace
concatenation by use of message formatters, which allow the localizer to position the
variable information appropriately.
- Handle Numbers, Currencies, Dates and Times: Number and date formats can also
be used separately, with similar control over their formatting. Number formatters handle
general numbers and currencies; date formatters cover both dates and times. To globalize
your program, you can either use the defaults for the local language, or provide a pattern
that specifies the precise format you want, which is adapted to the language conventions.
- Fix String Comparison: Standard string comparisons only do a binary comparison.
For display strings this is almost always incorrect. Wherever the ordering or equality of
strings is important to the user, such as when presenting an alphabetized list, then use a
Collator. Otherwise you will find that you don't equate two strings that your user thinks
are equal.
- Use Character Properties: If your code assumes that all characters of a given
type (such as letters or digits) are the ones in the ASCII range, then it will break with
foreign languages. Rather than test for particular ranges of characters, you should use
the Unicode character properties wherever possible.
- Extend Word-Break Detection: Text boundaries are detected differently for
different languages. The ICU provides different break iterators to find word boundaries,
line-wrap boundaries, sentence boundaries and character boundaries.
- Convert Non-Unicode Text: Whenever you are dealing with different character
sets, you are faced with the problems of converting between them. Even if you are not
using Unicode, The ICU provides character set converters for converting in and out of
Unicode. These provide both high and low level support. At a low level, you have a simple
interface for converting strings. At a low level, you have full control over the process,
so that you can precisely control buffering, and handle edge cases as appropriate.
- Handle Multilingual Text: All of the formats, collators, and other classes in
the ICU allow you to pass an explicit Locale as a parameter. This means that you can give
the user the choice of which locales to use for display. For instance, you could generate
HTML that has French currencies in one column of a table and German currencies in another.
Return to top
