ZK Developer's Reference/Internationalization/Labels

Overview

For a multilingual application, it is common to display the content in the language that the end user prefers. Here we discuss the built-in support called internationalization labels.

However, if you prefer to use other approach, please refer to the Use Other Implementation section.

Internationalization Labels

The internationalization labels of an application are loaded from properties files based on the current locale. A properties file is a simple text file encoded in UTF-8. The file contains a list of key=value pairs, such as

# This is the default LabelsBundle.properties file
s1=computer
s2=disk
s3=monitor
s4=keyboard

By default the property file must be placed under the WEB-INF directory and named as i3-label_lang_CNTY.properties., where lang is the language such as en and fr, and CNTY is the country, such as US and FR.

If you want to use one file to represent a language regardless the country, you could name it i3-label_lang.properties, such as i3-label_ja.properties. Furthermore, i3-label.properties is the default file if the user's preferred locale doesn't match any other file.

When an user accesses a page, ZK will load the properties files for the user's locale. For example, assume the locale is de_DE, then it will search the following files and load them if found:

1. i3-label_de_DE.properties
2. i3-label_de.properties
3. i3-label.properties

By default, one properties file is used to contain all labels of a given locale. If you prefer to split it to multiple properties files (such as one file per module), please refer to the Loading Labels from Multiple Resources section.

Also notice that all files match the given locale will be loaded and merged, and the property specified in, say, i3-label_de_DE.properties will override what are defined in i3-label_de.properties if replicated. It also means if a label is the same in both de_DE and de, then you need only to specify in i3-label_de.properties (and then it will be inherited when de_DE is used). Of course, you could specify it in both files.

---

Access Internationalization Labels In ZUML

Use labels

Since 5.0.7 and later, an implicit object called labels was introduced, such that you could access the internationalization labels (so-called internationalization labels) directly. For example, assume you have a label called app.title, and then you could:

<window title="${labels.app.title}">
...
</window>

The labels object is a map (java.util.Map), so you could access the label directly by use of labels.whatever in an EL expression. Moreover, as shown above, you could access the label even if a key is named as aa.bb.cc (a string containing dot), such as app.title in the above example.

If the key is not a legal name, you could use labels['key'] to access, such as labels['foo-yet'].

When an internationalization label is about to be retrieved, one of i3-label_lang_CNTY.properties will be loaded. For example, if the Locale is de_DE, then WEB-INF/i3-label_de_DE.properties will be loaded. If no such file, ZK will try to load WEB-INF/i3-label_de.properties and WEB-INF/i3-label.properties in turn.

Use c:l('key')

With 5.0.6 or prior, you could, to get an internationalization label, use ${c:l('key')} in EL expression. For example,

<?taglib uri="http://www.zkoss.org/dsp/web/core" prefix="c"?>

<window title="${c:l('app.title')}">
 ...
</window>

Notice that the l function belongs to the TLD file called http://www.zkoss.org/dsp/web/core, so we have to specify it with the taglib directive as shown above.

Use c:l2('key') to format the message

If you'd like to use the label as a pattern to generate concatenated message with additional arguments (like java.text.MessageFormat does), you could use the l2 function

For example, let us assume we want to generate a full name based on the current Locale, then we could use ${c:l2('key',args)} to generate concatenated messages as follows.

<?taglib uri="http://www.zkoss.org/dsp/web/core" prefix="c"?>
<label value="${c:l2('fullname.format', fullname)}">

where we assume fullname is a string array (such as new String[] {"Jimmy", "Shiau"}).

Labels.getLabel(String, Object[]) assumes the content is a valid pattern accepted by MessageFormat, such as "{1}, {0}".

Access Internationalization Labels In Java

To access labels in Java code (including zscript), you could use Labels.getLabel(String), Labels.getLabel(String, Object[]) and others.

String username = Labels.getLabel("username");

Here is a more complex example. Let us assume we want to generate a full name based on the Locale, then we could use Labels.getLabel(String, Object[]) to generate concatenated messages as follows.

public String getFullName(String firstName, String lastName) {
   return Labels.getLabel("fullname.format", new java.lang.Object[] {firstName, lastName});
}

Labels.getLabel(String, Object[]) assumes the content is a valid pattern accepted by MessageFormat, such as "{1}, {0}".

Encoding character set

By default, the encoding of properties files are assumed to be UTF-8. If you prefer another encoding, please specify it in a library property called org.zkoss.util.label.web.charset. It also means all properties files must be encoded in the same character set.

For more information, please refer to ZK Configuration Reference.

Loading Labels from Multiple Resources

It is typical to partition the properties file into several modules for easy maintenance. Since 5.0.7 and later, you could specify the location for each of these properties file with the label-location element. For example,

<system-config>
    <label-location>/WEB-INF/labels/order.properties</label-location>
    <label-location>/WEB-INF/labels/invoice.properties</label-location>
</system-config>

Notice that, once you specify label-location, the default loading of /WEB-INF/i3-labels.properties won't take place. In other words, only the properties files specified in the label-location elements are loaded. Thus, if you'd like to load /WEB-INF/i3-labels.properties too, you have to add it to label-location with others.

In additions to the servlet path, you could specify a file path by starting with file:/. For example, file:/foo/labels.properties. If the target environment is Windows, you could specify the drive too, such as file:/C:/myapp/foo.properties. The advantage is that addition properties files could be added after the project has been built into a WAR file.

<system-config>
    <label-location>file:/labels/order.properties</label-location>
    <label-location>file:/labels/invoice.properties</label-location>
</system-config>

Notice that the configuration with a path related to the file system is better not to be part of WEB-INF/zk.xml, since it is error-proning for deployment. Thus, it is better to used in the addition configuration file which could be specified in a library property called org.zkoss.zk.config.path.

For 5.0.6 and older, you could use the approach described in the following section to load multiple properties files.

Loading from Database or Other Resources

If you prefer to put the internationalization labels in, say, database, you could extend the label loader to load labels from other locations, say database. It can be done by registering a locator, which must implement either LabelLocator or LabelLocator2. Then, invoke Labels.register(LabelLocator) or Labels.register(LabelLocator2) to register it.

If you can represent your resource in URL, you could use LabelLocator (as show below). If you have to load it by yourself, you could use LabelLocator2 and return an input stream (java.io.InputStream).

For example, with ZK 5.0.6 and older, you could load labels from multiple properties files by use of the following code:

public class FooLocator extends org.zkoss.zk.ui.util.LabelLocator {
    private ServletContext _svlctx;
    private String _name;
    public FootLocator(SevletContext svlctx, String name) {
        _svlctx = svlctx;
        _name = name;
    }
    public URL locate(Locale locale) {
        return _svlctx.getResource("/WEB-INF/labels/" + name + "_" + locale + ".properties");
    }
}

Then, we could register label locators when the application starts by use of WebAppInit as follows.

public class MyAppInit implements org.zkoss.zk.ui.util.WebAppInit {
    public void init(WebApp wapp) throws Exception {
        Labels.register(new FooLocator((ServletContext)wapp.getNativeContext(), "module-1");
        Labels.register(new FooLocator((ServletContext)wapp.getNativeContext(), "module-2");
    }
}

where we assume module-1.properties and module-2.properties are two modules of messages you provide. Then, you configure it in WEB-INF/zk.xml as described in ZK Configuration Reference.

---

Reload Labels Dynamically

The internationalization labels are loaded when a locale is used at the first time. It won't be reloaded automatically if the file is modified. However, it is easy to force ZK to reload by use of Labels.reset().

For example, you could prepare a test paging for reloading as follows.

<zk>
<button label="Reload Labels" onClick="org.zkoss.util.resource.Labels.reset();execution.sendRedirect(null);"/>
Test result: ${foo} ${another.whatever}
</zk>

Use Other Implementation

If you prefer to use other implementation (such as property bundle), you could implement a static method and map it with xel-method. Then, you could reference it in EL expressions. For example,

<?xel-method prefix="c" name="label" class="foo.MyI18Ns" 
  signature="java.lang.String label(java.lang.String)"?>
<window title="${c:label('app.title')}">
....
${c:label('another.key')}
</window>

Version History

Version	Date	Content
5.0.5	October 2010	LabelLocator2 was introduced.
5.0.7	March 2011	The labels object was introduced.