incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arash Rajaeeyan" <arash.rajaee...@gmail.com>
Subject Re: Re: Formatting locale vs. translation locale
Date Tue, 24 Oct 2006 09:14:01 GMT
Hi Adam,

let me clear that I think separating Formatting locale and translation
locale is a very good idea.

there are lots of methods in JSF to get current locale,
my point is to make sure these methods don't return some thing in conflict
with each other.
for example we must make sure the other components on the page you mentioned
are not searching for German translation of texts.

the same concept can also be extended to direction, users whose language is
written from right to left like Hebrew, Arabic and Farsi may prefer their
menu, trees, tabs, etc to be right aligned, and behave how they expect even
if the text is still in English.
for example scroll bars in left side is common in right to left languages,
and if your browser has put one scroll bar in left, and a JSF page displayed
in the browser has put scroll bar in right side of the page it becomes very
confusing.



On 10/24/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
> >
> >
>



-- 
Arash Rajaeeyan

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