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: Re: Formatting locale vs. translation locale
Date Tue, 24 Oct 2006 21:41:46 GMT
thanks adam
useful hints as usual

On 10/25/06, Adam Winer <awiner@gmail.com> wrote:
>
> 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
> >
> >
>



-- 
Arash Rajaeeyan

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