[
https://issues.apache.org/jira/browse/SLING-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052080#comment-13052080
]
Alexander Klimetschek commented on SLING-1905:
----------------------------------------------
Thanks!
> 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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
