+1 for Gab's suggestion of #1 and optionally #2. For the users you have to make a distinction between the ones who know a bit more about the internet and the novices. The former will expect the same date-format as the locale the page is in, the latter will expect to be able to enter their standard date format.
E.g., I'll expect to enter a US-Style date in an US-based web-application if the front-end is not in German (and I make the distinction based on the domain, .com generally means us-based means this strange way of defining dates ;). Whenever I'm thinking about localization, I'm thinking of this funny story: when I went to the US in summer of 2000, I had just turned 21. Imagine how often I had to tell to guys who carded me that indeed, I was 21, since 11th of June, and not going to be 21 on 6th of November! Imagine how thirsty I would have been without beer in the US for 3 months.... brrr.... regards, Martin On 10/25/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
Right! I am able to read english content, but I have no idea how english speaking guys enter their dates. Or more true, I don't care. In a *corperate* application, I am fine w/ reading english content, but want my German date format :) -M On 10/25/06, Gabrielle Crawford <[EMAIL PROTECTED]> wrote: > What's the problem with running in German with fr_ca formatting locale? > Basically if you're entering dates you want to let the user enter them > in the way they are used to, if the help can support it. If I'm German > and go to an English page, I think I would be quite happy if I could > enter the date, numbers, etc in the way I'm used to. > > I guess I think the reason locale was put on converters was to let users > format data in the way they are used to, even if the language/country is > different. > > Thanks, > > Gab > > Simon Lessard wrote: > > > It's true that en_US and en_GB can cause a problem. However this will > > hold > > true only if the language is the same. So, if we implements that maybe we > > can limit the valid formatting locales to those sharing the same language > > and only switch the country? That way it will be impossible to get in a > > state of German translation with fr_ca formatting. > > > > On 10/25/06, Gabrielle Crawford <[EMAIL PROTECTED]> wrote: > > > >> > >> > >> > >> Simon Lessard wrote: > >> > >> > I'm so divided on this issue that I think I'll call a +0 on my side. > >> > When I > >> > go on a site in English, I expect the date to be formatted > >> > accordingly. On > >> > >> I couldn't tell from the comment what you meant exactly. It may be > >> obvious when you switch languages, but you may not switch languages. If > >> I'm in the UK running in English I will expect UK date formatting, which > >> I think means day-month-year, and not month-day-year. I think it's > >> pretty subtle that you're actually running in en-us and not en-gb, I > >> don't expect the user to know that. > >> > >> > the other hand, some user are... well... hmmm... not so comfortable > >> with > >> > computers and could completely ignore that date can even appear in > >> > more than > >> > one format. Anyway, whatever decision is taken, I agree with Martin > >> that > >> > we'll need to indicate it clearly. > >> > >> So I suggested we use a config param, the default is 1, but you can 'buy > >> in' and set it to 2. What do people think of that? > >> > >> Thanks, > >> > >> Gab > >> > >> > > >> > > >> > Regards, > >> > > >> > ~ Simon > >> > > >> > On 10/25/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > >> > > >> >> > >> >> 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 > >> >> > >> > > >> > >> > > > > -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
