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
