Begin Important Note:
In spite of statements to the contrary below, only a few of the strings in
the core Protege system are currently localizable (as of April 8, 2004), and one
string from the standard_extensions plugin (the Query tab label). Once I receive feedback that the current scheme is useful and
workable the other strings in the core system will be exported in a similar
fashion at some later date. Also, there are no resource bundles
available right now in the library, although I would like for there to be....
End Import Note
Protege release 2.1 has improved support for internalization. In particular, all fixed English text in the Protege GUI can be replaced by end users with text from other languages. The system provides easy standard ways for plugins to provide this support as well so that end users can localize plugin text. Versions of this text (which we will refer to as "resource bundles") for some languages are available for download from the library on our web site. End users may also develop and use their own versions and we hope they will contribute them to our library. This page describes how to develop and use a Protege resource bundle.
The mechanism described here is used to replace the "fixed text" in the application. This includes menu items, tab names, labels, and dialog titles. It does not provide a mechanism for authoring knowledge-bases in multiple languages simultaneously. Such support is entirely separate and may follow at some later date.
Protege support for internalization and localization is directly layered on top of the built-in Java support. Those already familiar with the way that support works will find the scheme described here easy to understand. Those not familiar with this support may wish to browse the links on this page and the http://java.sun.com web site for additional background information.
A resource bundle is essentially one or more Java "properties" files. An example properties file is available here. Associated with every plugin and language combination is a separate resource bundle. Thus there is a Protege-French resource bundle, and a standard_extensions-German resource bundle. Each file in a bundle has a name <something>.properties. The core Protege files go in the Protege installation directory and are named "protege_text_<language_and_country>.properties". The properties files for a plugin goes in that plugin's installation directory and are named something like <plugin_name>_text_<language_and_country>.properties. The exact name for the plugins files are chosen by the plugin author.
These properties files contain the strings used by the application. There can be simultaneous English, French, and German versions of these strings available in the same Protege installation since each file will have its own unique name. There will also be variants of these properties files such as specific "Canadian French", "Swiss French", "Australian English" versions. When the system starts up the locale of the application is checked and the closest available set of files are loaded. Thus a user in Geneva might start up the application and strings would be loaded first from the "Swiss French", then from the "French", and then from the "default" properties file. This sort of mechanism decreases maintenance problems because the country specific files, if needed at all, can be quite small, only providing "overrides" where default language provides a value that is undesirable for the language dialect spoken in that country.
A Java properties file is just a list of "key-value" pairs. There is a "key" associated with every piece of text that needs to appear in the application. The "value" is the string that appears in the application. Thus, when the program needs a string, it accesses it from this file in a standard way using a key and displays whatever value is returned. Note that the program must be specifically written to access strings in this manner. If a plugin has not been written to be localizable then you cannot localize it by providing a resource bundle. You instead need to make modifications to the source code (or talk the original plugin developer into doing so).
You need to simply place the relevant properties files in the installation directory for the program you are trying to localize. For Protege itself this is the Protege installation directory; for a plugin it is the plugin's installation directory. When Protege starts up it prints out the language and country that it believes is appropriate for you based on your system. The language and country are both two letter codes. The language is always lower case and the country is always upper case. These codes are used in identifying the resource bundle that the system will use.
You may whish to use a resource bundle other than the one that is the default for your system. To do this you need to override the language/country that the Java runtime system reports to the application. To do this, set the Java properties: "user.language" to the two-character code that you want. If you need to, you can also specify the dialect of the language by country by setting the "user.country" Java property. You can specify these properties in the Protege.lax file or on the Java command line, depending on how you start Protege.
A list of the two-character language codes is available at:
http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt
and a list of the two-character country codes is available at:
http://www.chemie.fu-berlin.de/diverse/doc/ISO_3166.html
First let's discuss how NOT to develop a resource bundle. Please do not change the default existing .properties file. Any changes you make will be overwritten and lost every time you install a new version of the application or plugin.
The first step is to take the existing properties file, copy it, and rename it with the
appropriate language/country part. Note that the language code is always lower
case while the country code is always upper case. Thus a French file
should be named:
protege_text_fr.properties
and a Swiss French file should be named:
protege_text_fr_CH.properties
This case sensitivity will not show up on MS Windows based systems but will be
important if any Unix or Mac users want to use your bundle.
As indicated above you should develop the "generic" language file (say "French") first and then develop country specific files (say "Swiss French") later, as needed. The country specific files should only provide text for keys whose value you want to override.
Now edit the properties file it in your favorite text editor. Note that you must not change the value of the "key" for any entry (the value on the left of the '='). You are only changing the values on the right of the '='. Enter the translations for all values.
NB: Unfortunately the properties file must be in ISO Latin-I encoding with Java unicode escape characters in order to be used by the system. This restriction is a Java library "feature" and not a Protege implementation decision. This restriction seems to have been designed to make it as easy as possible for American Java programmers to do language translations and as difficult as possible for anyone else. A group of people less willing and able to do language translations than American Java programmers would be difficult to imagine. Nevertheless this restriction is real and must be worked around. There are two ways to do this:
This restriction is described in somewhat more detail here
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html
More information (programmer documentation) about loading resource
bundles is available here:
http://java.sun.com/j2se/1.4.2/docs/api/java/util/ResourceBundle.html