Hi Adam, let me clear that I think separating Formatting locale and translation locale is a very good idea.
there are lots of methods in JSF to get current locale, my point is to make sure these methods don't return some thing in conflict with each other. for example we must make sure the other components on the page you mentioned are not searching for German translation of texts. the same concept can also be extended to direction, users whose language is written from right to left like Hebrew, Arabic and Farsi may prefer their menu, trees, tabs, etc to be right aligned, and behave how they expect even if the text is still in English. for example scroll bars in left side is common in right to left languages, and if your browser has put one scroll bar in left, and a JSF page displayed in the browser has put scroll bar in right side of the page it becomes very confusing. On 10/24/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 > >
-- Arash Rajaeeyan
