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
