Re: Formatting locale vs. translation locale

[Gabrielle Crawford]

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
> > >
> > >
> >
>
>