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 <rhai...@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 > >
