Arash, ViewHandler.calculateLocale() is used to set the Locale on the UIViewRoot; so no conflicts really. They're different Locales.
There's two possibilities here, though, for the default behavior: (1) RequestContext.getFormattingLocale() defaults to just returning null; so, UIViewRoot.getLocale() - and, therefore, ViewHandler.calculateLocale() - always wins, unless someone explicitly calls setFormattingLocale() for a given request. (2) The formatting locale defaults independently of ViewHandler.calculateLocale() and the "supported-languages" list, based on the user agent "Accepts". So, for example, if you only had English as a supported language, a German user would see English text, but German-formatted dates out-of-the-box. I'm leaning towards #1, because it doesn't change any existing behavior, and even if we implement #1, and application developer can still choose to make an application behave like #2. But #2 is more like how I'd want my applications to behave... -- Adam On 10/23/06, Arash Rajaeeyan <[EMAIL PROTECTED]> wrote:
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
