ResourceBundleclass for each new
These are serious defects.
In addition, there are many nuisances associated with using
ResourceBundles and their
associated properties files:
native2asciitool must be used to process the files. (Rather impolite for an internationalization mechanism, is it not?)
blah=blahin a properties file. Such duplication makes most programmers justifiably nervous. (If a database is used, a
ResultSethaving the same
blah=blahstructure can be easily created, but without any actual data repeated in the underlying tables.)
MessageFormatclass 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
RuntimeExceptionis 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.)
ResourceBundlemechanism 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
package of the WEB4J tool. It uses a technique called
"last second localization".