You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Endolf (JIRA)" <ji...@apache.org> on 2012/07/17 17:17:33 UTC
[jira] [Created] (SLING-2536) JcrResourceBundle breaks the contract
of getLocale
Endolf created SLING-2536:
-----------------------------
Summary: 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
[jira] [Commented] (SLING-2536) JcrResourceBundle breaks the
contract of getLocale
Posted by "Endolf (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421288#comment-13421288 ]
Endolf commented on SLING-2536:
-------------------------------
If I choose sv, or any of it's variations and have the sv bundle in the repository it resolves that fine from just the accept-language header.
> 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
[jira] [Commented] (SLING-2536) JcrResourceBundle breaks the
contract of getLocale
Posted by "Endolf (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421262#comment-13421262 ]
Endolf commented on SLING-2536:
-------------------------------
That doesn't appear to be how it is working.
I only have english bundle installed, I set my browser language to only allow zh-hk, hong kong chinese, I can see that my Accept-Langauge in the request headers only contains that language. Sling is set to default to english.
The response contains a content-language header of zh-hk, all the properties are resolved to their english values, not the keys.
> 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
[jira] [Commented] (SLING-2536) JcrResourceBundle breaks the
contract of getLocale
Posted by "Alexander Klimetschek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13418531#comment-13418531 ]
Alexander Klimetschek commented on SLING-2536:
----------------------------------------------
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
[jira] [Commented] (SLING-2536) JcrResourceBundle breaks the
contract of getLocale
Posted by "Alexander Klimetschek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421285#comment-13421285 ]
Alexander Klimetschek commented on SLING-2536:
----------------------------------------------
That's probably because it resolves the english resource bundle. The default locale resolver does not use the accept-language header afaik.
> 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
[jira] [Commented] (SLING-2536) JcrResourceBundle breaks the
contract of getLocale
Posted by "Endolf (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421396#comment-13421396 ]
Endolf commented on SLING-2536:
-------------------------------
getLocale() always returns the locale that was asked for, even when it's fallen back to something else. I can't paste the code in here, but here is what I've done.
I've extended the SetBundleTag from the standard el tag library, in the doEndTag I get the locale from the request from pageContext, then I get the request, cast to a SlingHttpServletRequest and call the getResourceBundle method passing in the bundle basename and the locale I just got from the request.
I think store that in javax.servlet.jsp.jstl.fmt.localizationContext in page context so that the standard fmt tags can use the bundle.
We then just use the standard tags to access the bundle as we would in any other j2ee app.
> 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
[jira] [Commented] (SLING-2536) JcrResourceBundle breaks the
contract of getLocale
Posted by "Alexander Klimetschek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421393#comment-13421393 ]
Alexander Klimetschek commented on SLING-2536:
----------------------------------------------
What does request.getLocale() return? How does your code look like?
> 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
[jira] [Comment Edited] (SLING-2536) JcrResourceBundle breaks the
contract of getLocale
Posted by "Alexander Klimetschek (JIRA)" <ji...@apache.org>.
[ 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