On 10/24/06, Arjuna Wijeyekoon <[EMAIL PROTECTED]> 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.

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

Reply via email to