[
https://issues.apache.org/jira/browse/SLING-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15996309#comment-15996309
]
Stefan Seifert commented on SLING-6826:
---------------------------------------
my use case:
* sling and some downstream applications use the english text as i18n key for
translations. in this case nor hierarchy is required or useful.
* but we always have avoided this pattern in our application because:
** whenever the english text changes (for whatever reason), the key contract is
broken and all translations have to be touched as well
** it is not possible to "namespace" i18n keys to separate different
applications deployed by different parties on the same instance
* so we use a more traditional approach for our i18n keys like
"<application>.<section>.<component>.<key>".
* the master files we create with the original english texts (and sometimes
also the translations if the file is not too big) are maintained "by hand" by
the developer. in this case it is very helpful to use nested hierarchies to
avoid redundancy in the keys and cluster keys that belong to each other
together.
example:
{code:javascript}
{
"application1": {
"section1": {
"component1": {
"key1": "value1",
"key2": "value2"
}
}
}
}
{code}
> i18n: Supported nested keys in JSON i18n files
> ----------------------------------------------
>
> Key: SLING-6826
> URL: https://issues.apache.org/jira/browse/SLING-6826
> Project: Sling
> Issue Type: New Feature
> Components: i18n
> Affects Versions: i18n 2.5.8
> Reporter: Stefan Seifert
>
> i18n supports resource files stored as JSON binary files in the repository:
> https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#json-file-based
> currently nested key structures are not really supported - from the docs
> page:
> {quote}
> The parser will take any "key":"value" pair in the JSON file, including those
> in nested objects or arrays. Normally, a dictionary will be just a single
> json object = hash map though.
> {quote}
> that means that these two JSON example will produc the same result:
> A)
> {code:javascript}
> {
> "key1": "value1",
> "key2": "value2",
> "key3": "value3"
> }
> {code}
> B)
> {code:javascript}
> {
> "level1": {
> "key1": "value1",
> "level2: {
> "key2": "value2",
> "level3": {
> "key3": "value3"
> }
> }
> }
> }
> {code}
> in both cases the keys are just
> {noformat}
> key1
> key2
> key3
> {noformat}
> the goal of this ticket is to interpret the nested JSON object structure as
> parts of the i18n keys, so that example B would produce these keys:
> {noformat}
> level1.key1
> level1.level2.key2
> level1.level2.level3.key3
> {noformat}
> as statet in the documentation in most cases people will only use the JSON as
> key/value map file with no hierarchies at all. in this case the result is the
> same. but if someone used hierarchies this ticket will create a backward
> compatibility issue. i will start a discussion on the sling-dev list about
> this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
