[ 
https://issues.apache.org/jira/browse/SLING-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15995856#comment-15995856
 ] 

Alexander Klimetschek commented on SLING-6826:
----------------------------------------------

What is the use case for supporting nested json files?

At first glance, it only increases complexity to me (well, only a bit, but 
looking at future maintenance it might be). The json format is kind of 
proprietary (albeit it's dead simple) and is assumed to be converted from other 
dictionaries such as xliff etc. anyway...

Thus I also would be surprised if people are using it with nested json today, 
where not all contents would be used by sling i18n (to answer your question).


> 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)

Reply via email to