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