Arj, On 10/24/06, Arjuna Wijeyekoon <[EMAIL PROTECTED]> wrote:
I like #2 because: 1. no new public apis.
Maybe I didn't explain #2: in either case, we have a new public API. There's no way to add this feature without adding a public API. The question is entirely what the behavior of that public API is.
2. correct behaviour out-of-the-box
But what is "correct" behavior? Is it the current JSF behavior (formatting locale is always exactly translation locale), or is it that formatting locale is always exactly the user's locale, irrespective of the translation locale.
3. we won't get into a weird state where locale is english_uk, but someone programmatically sets formatting locale to english_us.
That's a complete legal state; maybe unusual, but legal. -- Adam
--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 > > > > >
