You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Robert Munteanu (JIRA)" <ji...@apache.org> on 2017/09/20 12:21:01 UTC

[jira] [Closed] (SLING-1905) Custom LocaleResolver cannot fall back to using the locale from the request's Accept-Language header

     [ https://issues.apache.org/jira/browse/SLING-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Munteanu closed SLING-1905.
----------------------------------

> Custom LocaleResolver cannot fall back to using the locale from the request's Accept-Language header
> ----------------------------------------------------------------------------------------------------
>
>                 Key: SLING-1905
>                 URL: https://issues.apache.org/jira/browse/SLING-1905
>             Project: Sling
>          Issue Type: Improvement
>          Components: Extensions
>    Affects Versions: I18n 2.0.4
>            Reporter: Alexander Klimetschek
>            Assignee: Felix Meschberger
>             Fix For: I18n 2.1.0
>
>
> It is difficult for a custom LocaleResolver to use the default request locale (based on the HTTP Accept-Language header), because:
> 1) the I18NFilter passes its own wrapped request object to the LocaleResolver (instead of the original one), resulting in an endless loop if request.getLocales() is used inside the LocaleResolver
> 2) LocaleResolver.resolveLocale() returns a List<Locale> whereas request.getLocales() returns Enumeration<Locale>, making conversion unnecessarily difficult
> 3) the default LocaleResolver which uses the original request's getLocale() is not available as a fallback, it is solely used if no custom LocaleResolver is used at all
> Ideas:
> 1) could easily be solved by passing this.getSlingRequest()
> 2) + 3) a public DefaultLocaleResolver class (as base for custom ones) could provide this fallback in its resolveLocale() implementation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)