[jira] Closed: (SLING-335) Implement Internationalization Support

["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.