Hi adam I have some experience of using ADF in countries which English is not primary language and their software needed to support more than one language at the same time.
having a RequestContext.getFormattingLocale() looks like a nice idea to me, and it makes it easier to add internationalization and support for different locales to components. I think t is much better that components act intelligently according to their users clients. it would be great if you could be sure this is no conflict with method: abstract java.util.Locale calculateLocale( javax.faces.context.FacesContext context) in following class of 1.1 API: javax.faces.application.ViewHandler On 10/23/06, Adam Winer <[EMAIL PROTECTED]> wrote:
JSF currently has support for one Locale, off of FacesContext.getLocale(). It's also possible to override the locale on a per-converter basis by explicitly setting the "locale" attribute on various converters. This is useful for cases when you have, for example, only translations into a limited set of languages (for example, just American English), but need to show users dates formatted in the user's locale so there is no accidental misinterpretation of dates (e.g., British English or German). I've gotten some internal requirements for using this functionality, but setting it on every single converter gets to be painful. To make this easier, I'd like to expose a new Locale on RequestContext: Locale RequestContext.getFormattingLocale() void RequestContext.setFormattingLocale(Locale locale) ... and have the DateTimeConverter and NumberConverter overrides that Trinidad supplies automatically default to the formatting locale if it is set to a non-null value. Comments? -- Adam
-- Arash Rajaeeyan
