Hi,
As far as I can see, displaytag doesn't support i18n by browser locale.
This is, however, an important feature in web applications we build.
I went a bit into the code, to see what could be done with minimal
effort
and without breaking compatibility. Unfortionately, displaytag mixes
functional
properties, layout and localized strings in one properties file. To
avoid
copying everything for every language, local strings should to be
taken out
of that ensemble.
This could be done by allowing property values to have embedded
resource
bundle keys.
Eg, a pattern of the form #{key} in the property value is replaced by
the
resource
value for 'key' at runtime.
The modified TableTag.properties could then look like this:
#----------------------------------------------------------------------
-----
---------
basic.msg.empty_list=#{table.empty}
basic.msg.empty_list_row=<tr class="empty"><td
colspan="{0}">#{table.empty}</td></tr>
basic.empty.showtable=false
basic.show.header=true
error.msg.invalid_page=#{invalid_page}
sort.amount=page
export.amount=list
export.decorated=true
export.banner=<div class="exportlinks">#{export.options}</div>
export.banner.sepchar= |
export.csv=true
export.csv.label=<span class="export csv">#{export.csv} </span>
export.csv.include_header=false
export.csv.filename=
export.excel=true
export.excel.label=<span class="export excel">#{export.excel} </span>
export.excel.include_header=true
export.excel.filename=
export.xml=true
export.xml.label=<span class="export xml">#{export.xml} </span>
export.xml.filename=
paging.banner.item_name=#{item_name}
paging.banner.items_name=#{items_name}
paging.banner.no_items_found=<span
class="pagebanner">#{items.none}</span>
paging.banner.one_item_found=<span
class="pagebanner">#{items.one}</span>
paging.banner.all_items_found=<span
class="pagebanner">#{items.all}</span>
paging.banner.some_items_found=<span
class="pagebanner">#{items.some}</span>
paging.banner.full=<span class="pagelinks">[<a
href="{1}">#{first}</a>/<a
href="{2}">#{prev}</a>] {0} [<a href="{3}">#{next}</a>/<a
href="{4}">#{last}</a>]</span>
paging.banner.first=<span class="pagelinks">[#{first}/#{prev}] {0} [<a
href="{3}">#{next}</a>/<a href="{4}">#{last}</a>]</span>
paging.banner.last=<span class="pagelinks">[<a
href="{1}">#{first}</a>/<a
href="{2}">#{prev}</a>] {0} [#{next}/#{last}]</span>
paging.banner.onepage=<span class="pagelinks">{0}</span>
paging.banner.group_size=8
paging.banner.page.selected=<strong>{0}</strong>
paging.banner.page.link=<a href="{1}" title="#{goto}">{0}</a>
paging.banner.page.separator=,
paging.banner.placement=top
css.tr.even=even
css.tr.odd=odd
css.th.sorted=sorted
css.th.ascending=order1
css.th.descending=order2
css.table=
css.th.sortable=sortable
# factory classes for extensions
factory.requestHelper=org.displaytag.util.DefaultRequestHelperFactory
# resource bundle to lookup #{key} parts in properties
i18n.bundle=org.displaytag.properties.TableTagStrings
# default language
i18n.language=en
#----------------------------------------------------------------------
-----
---------
The last two properties are new.
* the 'i18n.bundle' property contains the bundle name to resolve the
#{key}
parts in
properties.
* the 'i18n.language' property contains a default locale to use.
As usual, these can be overridden by users in their
displaytag.properties.
An english version of the externalized strings
(TableTagStrings.properties)
might look
like this:
#----------------------------------------------------------------------
-----
---------
table.empty = Nothing found to display.
export.options = Export options: {0}
export.csv = CSV
export.excel = Excel
export.xml = XML
invalid_page = invalid page
item_name = item
items_name = items
items.none = No {0} found.
items.one = One {0} found.
items.all = {0} {1} found, displaying all {2}.
items.some = {0} {1} found, displaying {2} to {3}.
first = First
prev = Prev
next = Next
last = Last
goto = Go to page {0}
#----------------------------------------------------------------------
-----
---------
As an example, the german counterpart (TableTagStrings_de.properties)
reads
like this.
#----------------------------------------------------------------------
-----
---------
table.empty = Keine Daten vorhanden.
export.options = Exportiere nach: {0}
export.csv = CSV
export.excel = Excel
export.xml = XML
invalid_page = Seite ungültig
item_name = Eintrag
items_name = Einträge
items.none = Kein {0} gefunden.
items.one = Ein(e) {0} gefunden.
items.all = {0} {1} gefunden, zeige alle {2}.
items.some = {0} {1} gefunden, zeige {2} bis {3}.
first = Erster
prev = Zurück
next = Weiter
last = Letzter
goto = Gehe zu Seite {0}
#----------------------------------------------------------------------
-----
---------
So far, so good.
Next, class org.displaytag.properties.TableProperties has to be
changed.
Basically,
* we construct instances by optionally passing in a locale.
* the bundle is loaded according to the specified locale.
* if no locale has been specified, we take the locale from the
'i18n.language' property.
* if that isn't set either, we use Locale.getDefault().
* when serving property values, we replace the #{key} parts in our
properties.
Now, if we do not always want to use a default locale, the table tag
has to
compute and pass the desired locale to the TableProperties constructor.
One way is to simply use request.getLocale() to take the locale
preferred by
the user.
I have done things up to this point and it works fine.
However, it is probably desired to explicitely state the locale (or at
least
language)
to be used. One possibility was to add an optional 'locale' attribute
to the
table tag
which would take a locale string like 'en_US', or one of the values:
* 'server' to take Locale.getDefault()
* 'request' to take request.getLocale()
* 'default' take locale constructed from 'i18n.language' property
It is possible to implement these changes without breaking
compativility.
Displaytag
could come with a bunch of TableTagString_xy.properties files and
would then
really
support i18n.
What do you think?
- Christoph
