T5.3 - Localization is only partially implemented?

[Robert Hailey <rh...@allogy.com>]

As far as I can tell from reading the code, there is what seems to be a pretty big hole in Tapestry's handling of localization.

Suppose I have set these as my supported locales: "en,fr,de"

...and further suppose that a request comes in with this accept-language header "klingon,de,fr"

The code seems to only operate on request.getLocale() [which is to say, "klingon"], which it does not support, and falls back to "en" (the only incorrect choice, in this case).

This seems easy enough to fix, but quite strange... is this intentional? an oversight? is there some magic somewhere else that makes this actually work?

RootPathDispatcher.java:
	localizationSetter.setNonPeristentLocaleFromLocaleName(request.getLocale().toString());

ComponentEventLinkEncoderImpl.java:
	Locale locale = request.getLocale();
	localizationSetter.setNonPeristentLocaleFromLocaleName(locale.toString());

If this is a known issue, I would be very interested in any patches that have already been developed for this, or any relevant message thread links/titles (couldn't easily find any).

--
Robert Hailey

Re: T5.3 - Localization is only partially implemented?

[Robert Hailey <rh...@allogy.com>]

On 2014/05/20 (May), at 4:54 PM, Kalle Korhonen wrote:

> I don't know if there's an existing issue around this.
> Take a look and open a new one if no existing issues are found. Should be
> straightforward to get it fixed.
> 
> Kalle


Filed:
https://issues.apache.org/jira/browse/TAP5-2346

--
Robert Hailey

Re: T5.3 - Localization is only partially implemented?

[Kalle Korhonen <ka...@gmail.com>]

The incorrect choice is because "en" is set as as the default locale (see
http://tapestry.apache.org/localization.html). But you are right,
accept-language allows specifying a list of desired locales, whereas it
looks like the current implementation assumes the browser to request a
single locale only. I don't know if there's an existing issue around this.
Take a look and open a new one if no existing issues are found. Should be
straightforward to get it fixed.

Kalle


On Tue, May 20, 2014 at 2:07 PM, Robert Hailey <rh...@allogy.com> wrote:

>
> As far as I can tell from reading the code, there is what seems to be a
> pretty big hole in Tapestry's handling of localization.
>
> Suppose I have set these as my supported locales: "en,fr,de"
>
> ...and further suppose that a request comes in with this accept-language
> header "klingon,de,fr"
>
> The code seems to only operate on request.getLocale() [which is to say,
> "klingon"], which it does not support, and falls back to "en" (the only
> incorrect choice, in this case).
>
> This seems easy enough to fix, but quite strange... is this intentional?
> an oversight? is there some magic somewhere else that makes this actually
> work?
>
> RootPathDispatcher.java:
>
> localizationSetter.setNonPeristentLocaleFromLocaleName(request.getLocale().toString());
>
> ComponentEventLinkEncoderImpl.java:
>         Locale locale = request.getLocale();
>
> localizationSetter.setNonPeristentLocaleFromLocaleName(locale.toString());
>
> If this is a known issue, I would be very interested in any patches that
> have already been developed for this, or any relevant message thread
> links/titles (couldn't easily find any).
>
> --
> Robert Hailey
>
>