If you use displaytag in a multi-language application, you will probably need to translate html generated by displaytag as well. Displaytag supports i18n for html snippets used in the paging and export banner and for the title of column headers.
Using the
displaytag.properties
file you can set all the messages handled by displaytag.
Configuring:
paging.banner.one_item_found=One item found
Will make displaytag output
One item found
when only a row is displayed.
In order to support other languages you can add any number of additional files named
displaytag_LANGUAGE.properties
. For example, you can add a
displaytag_IT.properties
for italian users with the following content:
paging.banner.one_item_found=Un solo elemento trovato
You don't need to copy all the properties in any internationalized file (some of them are also
configuration properties which don't need to be translated at all). Configure displaytag properly in
the main
displaytag.properties
file and then replicate only the strings you want to translate.
There are a few different ways to define the content for a column header in the
column
tag:
title
attribute: the content of the title attribute will be used as is for the column header
titlekKey
attribute: the content of the titlekey will be used to lookup a resource in a resource bundle
and the value will be used in the column header. If the specified key can't be found the
???key???
title will be displayed.
title
and
titleKey
properties out, while using a
property
attribute: the content of the
property
attribute will be used to lookup a resource in the resource bundle. If not found, the same
(capitalized) value is used for the column header.
By default, displaytag will use JSTL to lookup the value in the
titleKey
attribute, miming the behaviour of the
fmt:message
tag. This means that you need a container which supports jstl and standard.jar in your
classpath: if you don't wish to use JSTL for i18n you will have a few other options (read the
"advanced" chapter below).
Displaytag will probably be used in an application where content is already internationalized using a specific framework, which should provide a way to resolve the current locale and to lookup properties in a resource bundle.
Displaytag provides a way to plug-in different adapters to use the same i18n support you are using in your application.
By default displaytag will use the locale specified in the request (i.e. the locale set in the user browser). This can be fine for a basic use, but you could need a way to override this selection and to force a different locale.
Here comes the problem: if you already use Jstl, Struts or other frameworks you will know that there is no standard way to specify the locale to use: each framework works in a different way.
Displaytag provides an interface
LocaleResolver
with a few ready to use implementations which match the behaviour of common frameworks. The locale
resolver is specified in the
displaytag.properties
file using the
locale.resolver
key.
If nothing is specified the locale from the request is used, as specified above. However, you are
free to configure here any custom implementation of the
org.displaytag.localization.LocaleResolver
interface with a simple method
resolveLocale(HttpServletRequest)
Displaytag provides by default these ready to use implementations:
| class name | behaviour |
|---|---|
| org.displaytag.localization.I18nJstlAdapter |
Mimic JSTL, looking for a locale specified in session with the
Config.FMT_LOCALE
key.
|
| org.displaytag.localization.I18nStrutsAdapter |
Struts adapter, will look for the locale specified by
Globals.LOCALE_KEY
|
| org.displaytag.localization.I18nWebworkAdapter | Webwork2 adapter, will look for the locale specified by the fist LocaleProvider action in the stack |
| org.displaytag.localization.I18nSpringAdapter |
Spring adapter, will use
RequestContextUtils.getLocale()
for locale resolution (which will in turn delegate to the Spring locale resolver)
|
Other than resolving the currently used locale, your framework will probably provide a standard way to store i18n resources. Just like for the locale resolution, displaytag will allow you to plug in different implementations.
Displaytag provides an interface
I18nResourceProvider
with a few ready to use implementations which match the behaviour of common frameworks. This is
configured in
displaytag.properties
using the
locale.provider
key. By default the JSTL implementation is used.
The ready to use locale resolvers are (yes, these are the same classes used for locale resolution, since they implement both interfaces):
| class name | behaviour |
|---|---|
| org.displaytag.localization.I18nJstlAdapter | JSTL implementation, works in the same way as fmt:message. Note that this depends from the jakarta jstl implementation: it will also work with Resin jstl support, but you will still need standard.jar in the classpath. |
| org.displaytag.localization.I18nStrutsAdapter |
Struts adapter, will use
TagUtils.message()
|
| org.displaytag.localization.I18nWebworkAdapter | Webwork2 adapter, will look for the first TextProvider action in the stack and will obtain a message for the given key. |
| org.displaytag.localization.I18nSpringAdapter |
Spring adapter, will look for the configured
messageSource
and use it to obtain a value for the given key.
|