sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek (JIRA)" <>
Subject [jira] [Commented] (SLING-6826) i18n: Supported nested keys in JSON i18n files
Date Wed, 03 May 2017 22:58:04 GMT


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

View raw message