I like #2 because: 1. no new public apis. 2. correct behaviour out-of-the-box 3. we won't get into a weird state where locale is english_uk, but someone programmatically sets formatting locale to english_us. --arjuna
On 10/23/06, Adam Winer <[EMAIL PROTECTED]> wrote:
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 > >
