[
https://issues.apache.org/jira/browse/SLING-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13418531#comment-13418531
]
Alexander Klimetschek edited comment on SLING-2536 at 7/19/12 6:22 PM:
-----------------------------------------------------------------------
Note that JcrResourceBundle is special in that it does not use a fallback (only
for getKeys()) - instead it returns the key if no translation was found (as it
is designed without any i18n message ids). This happens on a case-by-case
basis. So the JcrResourceBundle is always tightly bound to its locale,
returning the parent locale wouldn't make sense.
was (Author: alexander.klimetschek):
Note that JcrResourceBundle is special in that it does not use a fallback
(only for getKeys()) - instead it returns the key if no translation was found
(as it is designed with any i18n message ids). This happens on a case-by-case
basis. So the JcrResourceBundle is always tightly bound to its locale,
returning the parent locale wouldn't make sense.
> JcrResourceBundle breaks the contract of getLocale
> --------------------------------------------------
>
> Key: SLING-2536
> URL: https://issues.apache.org/jira/browse/SLING-2536
> Project: Sling
> Issue Type: Bug
> Affects Versions: i18n 2.2.2
> Reporter: Endolf
>
> The javadoc for getLocale state that it should return the locale of this
> bundle or the locale of the fallback. Currently JcrResourceBundle always
> returns the requested locale even if there is no mix:language for that locale.
> e.g. Only a mix:language with a jcr:language en is in the jcr, a request for
> a resource bundle of sv will return a ResourceBundle object where getLocale
> returns sv. This should return en according to the javadoc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
