[
https://issues.apache.org/jira/browse/SLING-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052839#comment-13052839
]
Tobias Bocanegra commented on SLING-1905:
-----------------------------------------
i don' think that the behavior of request.getLocales() is correct. according to
the servlet spec:
"Returns an Enumeration of Locale objects indicating, in decreasing order
starting with the preferred locale, the locales that are acceptable to the
client based on the Accept-Language header. If the client request doesn't
provide an Accept-Language header, this method returns an Enumeration
containing one Locale, the default locale for the server."
so the condition that request.getLocale() returns the default one, but
request.getLocales() is empty, is invalid.
Further the case where a configured localeResolver returns an empty list should
be delegated back to the original servlet request - or this behavior should at
least be configurable.
(can you please clarify or re-open the bug)
> 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
