incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: Re: Re: Formatting locale vs. translation locale
Date Tue, 24 Oct 2006 21:16:25 GMT
Arash,

No, there isn't a conflict.  Code looking for translations will all
use UIViewRoot.getLocale().

BTW, for reading direction, we already have a RequestContext
getReadingDirection() that can be overridden using
trinidad-config.xml.

-- Adam



On 10/24/06, Arash Rajaeeyan <arash.rajaeeyan@gmail.com> wrote:
> 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
View raw message