Feature Requests item #1015548, was opened at 2004-08-24 22:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=536616&aid=1015548&group_id=73068
Category: main taglib
Group: planned for 1.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Christoph Beck (beckchr)
Assigned to: Nobody/Anonymous (nobody)
Summary: i18n, support browser locale
Initial Comment:
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.
See the modified TableTag.properties file...
The last two properties in this file 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.
You can find english and german versions of the
externalized strings in the
files TableTagStrings.properties and
TableTagStrings_de.properties.
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.
Up to now, changes are 99.99% backward compatible
(the 0.01% is due to the fact,
that the string '#{' in a property value now has a special
meaning).
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 pageContext.getRequest
().getLocale() to take the
locale preferred by the user (single line change in
TableTag.doStartTag()).
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
Now, what would be the default? To keep backward
compativility, it would be 'default',
since displaytag nowerdays always uses english text as
default. On the other hand,
I would expect that it is almost always better to use the
user locale from the request.
It would be nice, if this (or some other) solution for i18n
support would be included
into displaytag 1.0.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=536616&aid=1015548&group_id=73068
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
displaytag-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/displaytag-devel
