Introduction
Normally two types of strings exist in applications:
- internal strings that need no translation into a locale language,
as they do not appear on any user interface, and
- strings that have to be translated into the locale language on
application
startup because they will be shown on some user interface.
The traditional way to internationalize
Java applications is to use
some
utility class like "Language" that stores the actual translations of
any
application-defined language-neutral string.
This requires the wrapping of any string
into some translation-call like "Language.get(neutralString)", and
resource-loading of property files that contain the translations
(see "Traditional" example below).
When you build a GUI from some XML specification (e.g. XUL),
that XML also will hold language-specific strings which have to be
translated by the building source-code.
This requires hardcoding the structure of the GUI specification:
element and attribute names have to be duplicated as source-code
strings to be able to access the XML.
In other words:
- We
have language-specific strings not only in Java code, but also in XML
documents!
But these XML files do not only hold language-specific texts, normally there is a
lot of semantic, too. In case the schema (structure) of that XML changes,
also the processing Java code has to be adapted.
This is a classical maintainance problem. The more XML is
used to externalize things, the more this aspect gets important.
Wouldn't it be nice to have internationalization on XML level, and maybe
use XML instead of property files and resource bundles? Besides, the Java
Properties
class does not support encodings, so eastern languages have
to be written using escape-sequences, which is not very readable.
XML supports an encoding declaration, so you can get rid of such cryptography.
By the means of an XSLT processor (contained in JDK since 1.4),
an internationalization as pure XML solution (without Java!) is possible, see
code below. This concept uses a separate XML file that contains only
translations.
- Translation texts find their target by using an "id" attribute in
the language-neutral XML file (so the latter has to provide such).
- The translation is done by an XSLT
stylesheet
that works generically, that means it does not depend on a certain document type,
only the "id" attribute must be present and unique.
- Launching
the XSLT transformation is the only part that has to be coded in some programming language.
Thus, such a solution can be used with any
programming-language that provides libraries for XML and XSLT
processing.
The following Java solution provides the same naming conventions as Java resource
bundles do: a file named strings.xml will
be translated by searching for strings_de.xml, strings_fr.xml, ..., according to the platform locale.
Each of these translation XML files can have its own encoding. This eases a translation by some third party:
you send the party e.g. an English file strings_en.xml
, and you get back
the Chinese translation strings_ch.xml
, without having to care about the encoding they use.
Just be aware that not any GUI font can render Chinese letters!
Traditional way to internationalize applications (using Java):
strings.properties:
Cancel=Default text for Cancel
strings_de.properties:
Cancel=Abbrechen
Application.java:
String
neutralButtonLabel = "Cancel";
JButton button = new
JButton(Language.singleton.get(neutralButtonLabel));
toolbar.add(button);