incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arjuna Wijeyekoon" <arj...@gmail.com>
Subject Re: Re: Formatting locale vs. translation locale
Date Tue, 24 Oct 2006 22:46:06 GMT
I like #2 because:
1. no new public apis.
2. correct behaviour out-of-the-box
3. we won't get into a weird state where locale is english_uk, but someone
programmatically sets formatting locale to english_us.
--arjuna

On 10/23/06, Adam Winer <awiner@gmail.com> 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 <arash.rajaeeyan@gmail.com> 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 <awiner@gmail.com> 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
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message