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
