I believe that #1 is what we should do. If you do #2, then the locale will be changed away from what the view-root offers (and which might be derived from the accept-header of the request, so you have the possibility to implement #2) somehow "automagically" - without the developer really knowing.
- First (that's the same issue as you had) - existing applications behave differently. - Second - also as a user, I'm expecting US-date format when I'm looking at an application I18nized in en-US. If you give me German date formats, you'll need to indicate this clearly, and that's something a developer has to do manually and consciously (except Trinidad has some automatic way of indicating date, time and number-format to the user). So as a German-speaking user, this is not the way I'd want the application to behave automatically. regards, Martin On 10/25/06, Gabrielle Crawford <[EMAIL PROTECTED]> wrote:
Arjuna Wijeyekoon wrote: > On 10/24/06, Adam Winer <[EMAIL PROTECTED]> wrote: > >> >> >> 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. > > > > ok, I see. you will still need the > RequestContext.getFormattingLocale but > not the setFormattingLocale. > > >> 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. > > > > ok, I see the problem. > Personally, I feel that the user's locale is always correct. > But if it is in conflict with the translation locale, I am not sure > what to > do. > Using a date field as an example, often there is a hint underneath the > field > indicating what the pattern is. > does this hint come from a translation bundle? If so, then it would be > wrong > to use the user's locale instead of the > translation locale. That's a very good point. If they only have US translations, the help uses US formatting, now we come along and actually use UK formatting, so the help is wrong. That does seem like a major problem for #2. Could we have a config setting to switch on #2, because I think #2 is very useful, but maybe they need to buy in, it's still a much less painful buy in than they have now with the converter 'locale' attribute.... Thanks, Gab > > >> 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. > > > > It is more than unusual. It is completely wrong. If I expect my dates > to be > in (UK) dd-MM-yyyy, and I am actually getting > (US) MM-dd-yyyy, that could cause me to miss my flight. > --arjuna > > -- 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 >> > > > >> > > > >> > > >> > >> > >> >
-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
