You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2008/03/14 17:12:24 UTC
[jira] Created: (SLING-335) Implement Internationalization Support
Implement Internationalization Support
--------------------------------------
Key: SLING-335
URL: https://issues.apache.org/jira/browse/SLING-335
Project: Sling
Issue Type: New Feature
Reporter: Felix Meschberger
Assignee: Felix Meschberger
Fix For: 2.0.0
The SlingHttpServletRequest interface defines a getResourceBundle(Locale) method which should return a ResourceBundle for the given locale. Currently this method is unimplemented - and erroneously always returns null, where it should just return an empty ResourceBundle.
It would be cool to have support for internationalization from resources stored in the repository : a mapping from key to message is stored in a node with the key and message being properties of the node. Multiple such nodes are stored below a language node. This subtree defines resources for a given language (aka locale).
For example resources for plain english "en" could be stored like this:
/some/path
+-- en
+-- jcr:language = "en"
+-- 0000
+-- sling:key = "msg001"
+-- sling:message = "OK"
+-- 0001
+-- sling:key = "Cancel"
+-- sling:message = "Cancel"
The reason to not store the message key as the node (or property) name is that this would limit the character set usable for keys. For example there are I18N usecases where the message key is simply the english message.
A mechanism will be built, which collects for a given language all language subtrees and creates a ResourceBundle. The language subtrees are found using JCR queries so, a ResourceBundle for a single locale may grab messages from various places around the repository (actually the resource tree).
Note that the name of the root of the language tree is not relevant, the jcr:language property indicates the locale to which the subtree pertaines. This allows for more user friendly naming. Yet, I suggest to still use the locale as the node name for clarity.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-335) Implement Internationalization Support
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger updated SLING-335:
------------------------------------
Component/s: Extensions
> Implement Internationalization Support
> --------------------------------------
>
> Key: SLING-335
> URL: https://issues.apache.org/jira/browse/SLING-335
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: 2.0.0
>
>
> The SlingHttpServletRequest interface defines a getResourceBundle(Locale) method which should return a ResourceBundle for the given locale. Currently this method is unimplemented - and erroneously always returns null, where it should just return an empty ResourceBundle.
> It would be cool to have support for internationalization from resources stored in the repository : a mapping from key to message is stored in a node with the key and message being properties of the node. Multiple such nodes are stored below a language node. This subtree defines resources for a given language (aka locale).
> For example resources for plain english "en" could be stored like this:
> /some/path
> +-- en
> +-- jcr:language = "en"
> +-- 0000
> +-- sling:key = "msg001"
> +-- sling:message = "OK"
> +-- 0001
> +-- sling:key = "Cancel"
> +-- sling:message = "Cancel"
> The reason to not store the message key as the node (or property) name is that this would limit the character set usable for keys. For example there are I18N usecases where the message key is simply the english message.
> A mechanism will be built, which collects for a given language all language subtrees and creates a ResourceBundle. The language subtrees are found using JCR queries so, a ResourceBundle for a single locale may grab messages from various places around the repository (actually the resource tree).
> Note that the name of the root of the language tree is not relevant, the jcr:language property indicates the locale to which the subtree pertaines. This allows for more user friendly naming. Yet, I suggest to still use the locale as the node name for clarity.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-335) Implement Internationalization Support
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger closed SLING-335.
-----------------------------------
Resolution: Fixed
Description of the consolidated internationalization support can also be found on the Sling site at http://incubator.apache.org/sling/site/internationalization-support.html (might take a while to by synched)
Closing this issue.
> Implement Internationalization Support
> --------------------------------------
>
> Key: SLING-335
> URL: https://issues.apache.org/jira/browse/SLING-335
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: 2.0.0
>
>
> The SlingHttpServletRequest interface defines a getResourceBundle(Locale) method which should return a ResourceBundle for the given locale. Currently this method is unimplemented - and erroneously always returns null, where it should just return an empty ResourceBundle.
> It would be cool to have support for internationalization from resources stored in the repository : a mapping from key to message is stored in a node with the key and message being properties of the node. Multiple such nodes are stored below a language node. This subtree defines resources for a given language (aka locale).
> For example resources for plain english "en" could be stored like this:
> /some/path
> +-- en
> +-- jcr:language = "en"
> +-- 0000
> +-- sling:key = "msg001"
> +-- sling:message = "OK"
> +-- 0001
> +-- sling:key = "Cancel"
> +-- sling:message = "Cancel"
> The reason to not store the message key as the node (or property) name is that this would limit the character set usable for keys. For example there are I18N usecases where the message key is simply the english message.
> A mechanism will be built, which collects for a given language all language subtrees and creates a ResourceBundle. The language subtrees are found using JCR queries so, a ResourceBundle for a single locale may grab messages from various places around the repository (actually the resource tree).
> Note that the name of the root of the language tree is not relevant, the jcr:language property indicates the locale to which the subtree pertaines. This allows for more user friendly naming. Yet, I suggest to still use the locale as the node name for clarity.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-335) Implement Internationalization
Support
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580062#action_12580062 ]
Felix Meschberger commented on SLING-335:
-----------------------------------------
Removed the locale resolution support from the sling/core module in Rev. 638555. This support has been moved to the new i18n module.
> Implement Internationalization Support
> --------------------------------------
>
> Key: SLING-335
> URL: https://issues.apache.org/jira/browse/SLING-335
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: 2.0.0
>
>
> The SlingHttpServletRequest interface defines a getResourceBundle(Locale) method which should return a ResourceBundle for the given locale. Currently this method is unimplemented - and erroneously always returns null, where it should just return an empty ResourceBundle.
> It would be cool to have support for internationalization from resources stored in the repository : a mapping from key to message is stored in a node with the key and message being properties of the node. Multiple such nodes are stored below a language node. This subtree defines resources for a given language (aka locale).
> For example resources for plain english "en" could be stored like this:
> /some/path
> +-- en
> +-- jcr:language = "en"
> +-- 0000
> +-- sling:key = "msg001"
> +-- sling:message = "OK"
> +-- 0001
> +-- sling:key = "Cancel"
> +-- sling:message = "Cancel"
> The reason to not store the message key as the node (or property) name is that this would limit the character set usable for keys. For example there are I18N usecases where the message key is simply the english message.
> A mechanism will be built, which collects for a given language all language subtrees and creates a ResourceBundle. The language subtrees are found using JCR queries so, a ResourceBundle for a single locale may grab messages from various places around the repository (actually the resource tree).
> Note that the name of the root of the language tree is not relevant, the jcr:language property indicates the locale to which the subtree pertaines. This allows for more user friendly naming. Yet, I suggest to still use the locale as the node name for clarity.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-335) Implement Internationalization
Support
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578842#action_12578842 ]
Felix Meschberger commented on SLING-335:
-----------------------------------------
Added a default implementation of the SlingHttpServletRequest.getResourceBundle(Locale) method which always returns an empty resource bundle in Rev. 637149.
> Implement Internationalization Support
> --------------------------------------
>
> Key: SLING-335
> URL: https://issues.apache.org/jira/browse/SLING-335
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: 2.0.0
>
>
> The SlingHttpServletRequest interface defines a getResourceBundle(Locale) method which should return a ResourceBundle for the given locale. Currently this method is unimplemented - and erroneously always returns null, where it should just return an empty ResourceBundle.
> It would be cool to have support for internationalization from resources stored in the repository : a mapping from key to message is stored in a node with the key and message being properties of the node. Multiple such nodes are stored below a language node. This subtree defines resources for a given language (aka locale).
> For example resources for plain english "en" could be stored like this:
> /some/path
> +-- en
> +-- jcr:language = "en"
> +-- 0000
> +-- sling:key = "msg001"
> +-- sling:message = "OK"
> +-- 0001
> +-- sling:key = "Cancel"
> +-- sling:message = "Cancel"
> The reason to not store the message key as the node (or property) name is that this would limit the character set usable for keys. For example there are I18N usecases where the message key is simply the english message.
> A mechanism will be built, which collects for a given language all language subtrees and creates a ResourceBundle. The language subtrees are found using JCR queries so, a ResourceBundle for a single locale may grab messages from various places around the repository (actually the resource tree).
> Note that the name of the root of the language tree is not relevant, the jcr:language property indicates the locale to which the subtree pertaines. This allows for more user friendly naming. Yet, I suggest to still use the locale as the node name for clarity.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-335) Implement Internationalization
Support
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580060#action_12580060 ]
Felix Meschberger commented on SLING-335:
-----------------------------------------
Comitted the new sling/i18n bundle in Rev. 638552.
This bundle contains internationalization support as described in this issue, that is a filter implementation supporting the getLocale(), getLocales() and getResourceBundle(Locale) methods of the SlingHttpServletRequest interface.
> Implement Internationalization Support
> --------------------------------------
>
> Key: SLING-335
> URL: https://issues.apache.org/jira/browse/SLING-335
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: 2.0.0
>
>
> The SlingHttpServletRequest interface defines a getResourceBundle(Locale) method which should return a ResourceBundle for the given locale. Currently this method is unimplemented - and erroneously always returns null, where it should just return an empty ResourceBundle.
> It would be cool to have support for internationalization from resources stored in the repository : a mapping from key to message is stored in a node with the key and message being properties of the node. Multiple such nodes are stored below a language node. This subtree defines resources for a given language (aka locale).
> For example resources for plain english "en" could be stored like this:
> /some/path
> +-- en
> +-- jcr:language = "en"
> +-- 0000
> +-- sling:key = "msg001"
> +-- sling:message = "OK"
> +-- 0001
> +-- sling:key = "Cancel"
> +-- sling:message = "Cancel"
> The reason to not store the message key as the node (or property) name is that this would limit the character set usable for keys. For example there are I18N usecases where the message key is simply the english message.
> A mechanism will be built, which collects for a given language all language subtrees and creates a ResourceBundle. The language subtrees are found using JCR queries so, a ResourceBundle for a single locale may grab messages from various places around the repository (actually the resource tree).
> Note that the name of the root of the language tree is not relevant, the jcr:language property indicates the locale to which the subtree pertaines. This allows for more user friendly naming. Yet, I suggest to still use the locale as the node name for clarity.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-335) Implement Internationalization
Support
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580055#action_12580055 ]
Felix Meschberger commented on SLING-335:
-----------------------------------------
Besides implementing the getResourceBundle(Locale) method, the new bundle should also implement support for the getLocale() and getLocales() method to centralize complete internationalization support in one single place.
> Implement Internationalization Support
> --------------------------------------
>
> Key: SLING-335
> URL: https://issues.apache.org/jira/browse/SLING-335
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: 2.0.0
>
>
> The SlingHttpServletRequest interface defines a getResourceBundle(Locale) method which should return a ResourceBundle for the given locale. Currently this method is unimplemented - and erroneously always returns null, where it should just return an empty ResourceBundle.
> It would be cool to have support for internationalization from resources stored in the repository : a mapping from key to message is stored in a node with the key and message being properties of the node. Multiple such nodes are stored below a language node. This subtree defines resources for a given language (aka locale).
> For example resources for plain english "en" could be stored like this:
> /some/path
> +-- en
> +-- jcr:language = "en"
> +-- 0000
> +-- sling:key = "msg001"
> +-- sling:message = "OK"
> +-- 0001
> +-- sling:key = "Cancel"
> +-- sling:message = "Cancel"
> The reason to not store the message key as the node (or property) name is that this would limit the character set usable for keys. For example there are I18N usecases where the message key is simply the english message.
> A mechanism will be built, which collects for a given language all language subtrees and creates a ResourceBundle. The language subtrees are found using JCR queries so, a ResourceBundle for a single locale may grab messages from various places around the repository (actually the resource tree).
> Note that the name of the root of the language tree is not relevant, the jcr:language property indicates the locale to which the subtree pertaines. This allows for more user friendly naming. Yet, I suggest to still use the locale as the node name for clarity.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.