[
https://issues.apache.org/jira/browse/SLING-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051986#comment-13051986
]
Felix Meschberger commented on SLING-1905:
------------------------------------------
Maybe calling the LocalResolver with the request wrapped by the I18N Filter is
probably wrong. The request used to call the LocaleResolver should be the
wrapped request.
Hence I suggest:
* Call the LocaleResolver with the request provided to the I18NFilter
* Move the existing DefaultLocaleResolver to the exported package (removing
the unneeded unwrapping)
> 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
>
> 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
