tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Dawson <tdaw...@wamnet.com>
Subject FW: i18n proposal: format tags & default locale
Date Sun, 14 Oct 2001 22:53:05 GMT
The i18n taglib has (finally) been updated as outlined in my earlier
message, with a few changes as noted below:

1. the 'setLocale' attribute was a little clunky (with a setter like
'setSetLocale...'), so I renamed it to 'changeResponseLocale'

2. the value for 'changeResponseLocale' always defaults to 'true', rather
than having the default depend upon whether or not the tag was empty.  the
reason for this was that under JSP 1.1, making the tag subclass
BodyTagSupport brings up the  nested-tag JspWriter problems which were fixed
in 1.2

3. an exception is no longer thrown if you try to mix languages.  this
allows French and English on the same page, since they use the same
character encoding, but will allow (and confuse) developers who try to mix
languages with different character encodings.

Please let me know if you see any problems with the latest checkins.

Thanks,

Tim

>  -----Original Message-----
> From: 	Tim Dawson  
> Sent:	Thursday, September 06, 2001 11:30 PM
> To:	'taglibs-dev@jakarta.apache.org'
> Subject:	i18n proposal: format tags & default locale
> 
> A question was recently brought up with respect to how the i18n format
tags work when a locale is not specified. James Strachan and I had an side
discussion, and we figured it would be best to make that discussion a bit
more public...
> 
> The issue at hand is that the format tags use the *response* locale by
default when one is not specified. More than one person has suggested that
the *request* locale should be used by defualt, since that locale will be
the one the user wants to use as a format.  The response locale, unless
changed by the developer, will default to whatever the JVM is using, e.g.
en-US for sites hosted in the US.
> 
> The major reason we didn't default to the request locale is that (IMHO)
the developer should control what kinds of locales are supported and/or
displayed by the site.  If I create a site that is laid out for a specific
language, having other formats might throw off the look and feel of my site
in a manner that I did not intend. (this is especially important for
currency formatting!)
> 
> Another good reason to use the response locale rather than the request
locale is integration with the bundle/message tags in the i18n taglib.  The
bundle tag determines from a list of preferred locales which one is best
supported by the site, based on the order of user preference and on which
locales are available for the selected bundle. The request locale is a
single value containing the first item from that list.  If the format tags
were to use the request locale as a default, the format tag could very well
choose a different locale than the one in use on the rest of the page.
> 
> All that said, developers need a way to specify the response locale, so
that the proper default can be used by the format tags.  Now, the bundle tag
(used with the message tags) by default sets the response locale. If the
bundle/message tags are in use, then no big deal, the current scheme works
fine.
> 
> But if only the format tags are in use, the developer needs a way to
specify the response locale. James suggested a new attribute to be set which
would cause the response locale to be set, i.e. <i18n:locale
setResponse="true"> would set the response from the request.  By default,
the locale tag would NOT set the response.
> 
> As I look at this, it occurs that the i18n:bundle tag is now a bit out of
parity with the i18n:locale tag, since the bundle tag *always* sets the
response locale.  Perhaps this should be an attribute as well? The big
difference here is that in order to support existing applications, the
setResponse would have to default to true in the case of the bundle tag --
something I'm not a big fan of since the locale tag would have the opposite
default, but I guess we could live with it.
> 
> Alternatively, we could have locale default to true if it has no body...
e.g. if the user is specifying <i18n:locale language="ja"/> then they
probably mean to set the default (and hence response) locale, but if they're
using <i18n:locale language="ja"><i18n:format.../></i18n:locale> then
they're probably just wanting to temporarily use a different locale.
> 
> Thoughts?  Right now I'm leaning towards:
> 
> Format tags
> 1. leaving format* tags to use the response locale if none is specified
> 2. adding setResponse attribute to i18n:locale
> 3. defaulting setResponse to true if i18n:locale has no body
> 4. defaulting setResponse to false if i18n:locale has a body
> 
> Message tags:
> 1. adding setResponse attribute to i18n:bundle> 
> 2. allowing i18n:bundle to provide a body
> 3. altering message tags (message, ifdef, ifndef) to look for a ancestor
18n:bundle tag if the bundleRef is not specified, and then to look for the
defaultBundle if no ancestor is found.
> 4. defaulting setResponse to true if i18n:bundle has no body (this is
current behavior since bundle doesn't currently allow a body)
> 5. defaulting setResponse to false if i18n:bundle has a body
> 6. if an ID for the bundle is not specified, become the default bundle
only if no body. if a body is there, the page still has no default bundle.
> 
> In general:
> 1. rely on developers to not do stupid things, like define bundle/locales
on the same page that cause conflicting charsets.
> 
> I think this approach, while somewhat different from the current
implementation, will be both backwards-compatible and make the usage of the
format tags and message tags look very similar.
> 
> Thoughts? I'm particularly interested to what people think about changing
the setResponse default based on whether the tag has a body or not...
> 
> Thanks,
> 
> Tim

Mime
View raw message