As far as I know, you can't do that with GWT's built-in i18n support.
If you don't like the ?locale=en_US in the URL, you can avoid it by
writing <meta> tags into the HEAD section of your host page, but,
regardless, you'll have to refresh the page. Why do you want to avoid
the refresh? If you're worried about losing application state, look
into GWT's history support.
Ian
At the moment, when using Messages or Constants you can't do that
because the different languages are realized with different HTML-
pages that must be loaded when changing the locale.
> something like : setLocale(new Locale.BR) and the page refresh all text
> data.
I'm thinking about this as well for a while because there are
projects where the change of the Locale during runtime is a
explicit requirement ruling out GWT at the moment.
You can solve that using GWT by not using the Constants/Messages-
framework but with the Dictionary-classes but that eliminates
the advantages you have with the interfaces allowing you to do
the compiler the job of checking the correct spelling of the keys.
Regards, Lothar
You mean, why do we need AJAX? We don't need it but if we have it
(here with GWT) there shouldn't be any exceptions.
> If you're worried about losing application state, look
> into GWT's history support.
I know it's a way but it's a very complicated way if you "only"
want to exchange the texts of all widgets that are implementing
HasLocalizableText (an interface I just made up right now ;-)
As the OP said, he just want to do a setLocale(new Locale.BR)
to change all localizable data on the page without caring what
the current state of the page is. That's nothing new, e.g.
Casabac (bought and abadoned by Software AG) allowed exactly that.
Regards, Lothar
No, I meant, "what's your reason?" not "why would you possibly want
that?!"--I was just trying to see if, for example, history support or
meta tags were enough to solve the problem.
>> If you're worried about losing application state, look
>> into GWT's history support.
>
> I know it's a way but it's a very complicated way if you "only"
> want to exchange the texts of all widgets that are implementing
> HasLocalizableText (an interface I just made up right now ;-)
>
> As the OP said, he just want to do a setLocale(new Locale.BR)
> to change all localizable data on the page without caring what
> the current state of the page is. That's nothing new, e.g.
> Casabac (bought and abadoned by Software AG) allowed exactly that.
Yeah, I kind of agree but with one really big caveat: the user's
locale seems like something that won't change much. I think, ideally,
it should change at most once because you should be able to sniff the
user's desired locale out of their HTTP request headers and, if you
have user accounts, you could store the user's preferred locale in
your database and make sure to set the correct locale every time they
log in.
I guess I'm saying that, to me, the trade off of (presumably) more
efficient i18n in exchange for having to request a new page to change
the locale is a fine one.
Ian