Internationalization
ResourceBundle
:
ResourceBundle
class for each new Locale
).
These are serious defects.
In addition, there are many nuisances associated with using ResourceBundle
s and their
associated properties files:
native2ascii
tool must be used to process the files.
(Rather impolite for an internationalization mechanism, is it not?)
blah=blah
in a properties file. Such duplication makes most programmers justifiably nervous. (If a
database is used, a ResultSet
having the same blah=blah
structure can be
easily created, but without any actual data repeated in the underlying tables.)
MessageFormat
class treats apostrophes as special characters. If an apostrophe appears
in a pattern passed to a MessageFormat
, it must be escaped, or else
a nice little RuntimeException
is thrown. If you send properties files to translators,
the probabilty of errors related to apostrophes is very high.
If a database is used instead of properties files, however, then
it's fairly easy to build a front end tool which can do the necessary validations.
(Building such a tool is especially attractive when it can be used with multiple projects.)
ResourceBundle
mechanism allows the caller to specify a module name,
which is mapped into a corresponding class name or properties file name. It's possible
to seriously question this design. In general, a method should not know the identity of its caller.
In summary, it seems that ResourceBundle
was intended
originally for desktop applications and properties files, and that its design is not robust
enough for easy use in the context of a web application backed by a database.
Fortunately, text translation is not a difficult task, and
creating an alternative to ResourceBundle
is actually fairly easy.
For an example, please see the
hirondelle.web4j.ui.translate
package of the WEB4J tool. It uses a technique called
"last second localization".