Simon Lessard wrote:
I'm so divided on this issue that I think I'll call a +0 on my side.
When I
go on a site in English, I expect the date to be formatted
accordingly. On
I couldn't tell from the comment what you meant exactly. It may be
obvious when you switch languages, but you may not
It's true that en_US and en_GB can cause a problem. However this will hold
true only if the language is the same. So, if we implements that maybe we
can limit the valid formatting locales to those sharing the same language
and only switch the country? That way it will be impossible to get in a
What's the problem with running in German with fr_ca formatting locale?
Basically if you're entering dates you want to let the user enter them
in the way they are used to, if the help can support it. If I'm German
and go to an English page, I think I would be quite happy if I could
enter the
Yes, and no... It depends on your users really. When I buy something from
USA I know how to enter the date because I'm used to it, all other sites
work that way.
If the site was somehow intelligent enough to see that I'm French Canadian
and to switch its date format accordingly, I would be quite
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
thanks adam
useful hints as usual
On 10/25/06, Adam Winer [EMAIL PROTECTED] 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
I like #2 because:
1. no new public apis.
2. correct behaviour out-of-the-box
3. we won't get into a weird state where locale is english_uk, but someone
programmatically sets formatting locale to english_us.
--arjuna
On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote:
Arash,
Arj,
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
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
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
I believe that #1 is what we should do. If you do #2, then the locale
will be changed away from what the view-root offers (and which might
be derived from the accept-header of the request, so you have the
possibility to implement #2) somehow automagically - without the
developer really knowing.
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
+1 for the FormatingLocale();
you mean facesCtx.getViewRoot().getLocale() right?
that's what the Trin Number/DateTime currently use when locale not set.
-M
On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote:
JSF currently has support for one Locale, off of FacesContext.getLocale().
It's also
Yep, that's the idea.
-- Adam
On 10/23/06, Gabrielle Crawford [EMAIL PROTECTED] wrote:
+1 for a formatting locale. If I'm understanding you correctly the
formatting locale would only be used for formatting, meaning 11-7-06 in
the US and 7-11-06 in Germany, but the error string will still use
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,
15 matches
Mail list logo
