incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <>
Subject Re: Re: Re: Re: Formatting locale vs. translation locale
Date Wed, 25 Oct 2006 22:47:32 GMT
On 10/24/06, Arjuna Wijeyekoon <> wrote:
> On 10/24/06, Adam Winer <> wrote:
> >
> >
> > On 10/24/06, Arjuna Wijeyekoon <> 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.

Not sure I follow.  There's no way we can get away with having
only one behavior here;  we need to support both the original
JSF behavior and this new customized behavior, per webapp
developer decision.  So, getFormattingLocale() has to
be customizable.  The two logical APIs here are:
  - setFormattingLocale()
  - EL: like readingDirection, use trinidad-config to set up EL
    that drives the formatting locale

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

Hints will have to be clever, that's true.  Not sure I have a good
solution for this.

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

No, not the point of this:  locale is en_UK, but formatting
locale is en_US could mean an English website is showing
dates to an American user.  Unusual, not not illegal.

Obviously, showing the wrong formats is a problem, or we
wouldn't be having this discussion!  I don't need to be
reminded of that. :)

-- Adam

View raw message