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.
-
You can reply to this email to add a comment to the issue online.
