[
https://issues.apache.org/jira/browse/SLING-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15998790#comment-15998790
]
Alexander Klimetschek commented on SLING-6826:
----------------------------------------------
{quote}this "((comment))" concept seems to be an AEM-only concept, not part of
sling{quote}
It doesn't have to, it just needs to use this convention in the dictionary, and
thus frees the Sling i18n layer from this complexity and allows different apps
to use different approaches, if they want.
{quote}the maven tool produced the flat json file in the target folder, not in
the source folder{quote}
This seems like something easy to change in the tool, no?
I just have the feeling that someone else might have different ideas on how
their json should look like in their development process and then this should
be added to sling i18n as well. Or your development flow and desired json
source format changes in the future.
IMO there should be a clear distinction between what the source translation
files are (such as your nested json, or in AEM we extract XLIFF from the source
code) and the _delivery_ dictionary files that sling i18n can pick up. The
latter should be kept as simple as possible in a key value format, as that's
also how java ResourceBundles "think" as well (we also explicitly designed the
((comment)) feature so that it does not impact sling i18n).
This way we keep these more fluctuating things (source file formats) out of
sling i18n and don't have to adopt it constantly.
> 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)
