[
https://issues.apache.org/jira/browse/SLING-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15998577#comment-15998577
]
Stefan Seifert commented on SLING-6826:
---------------------------------------
thanks for the feedback. the general concept of using natural text for i18n
keys has several pros and cons, let's not discuss it here further.
basename support is afaik not supported everywhere, e.g. in htl/sightly i18n
and AEM dialogs it's not supported.
this "((comment))" concept seems to be an AEM-only concept, not part of sling
(also htl/sightly supports it with "hint").
coming back to the ticket itself:
bq. Is having a plain json dictionary like this instead not feasible?
using a flat list of keys with "." as separator is semantically identically to
the JSON hierarchy with nested objects. tools that generate the json can always
decide to generate only the flat list, with the same result. but yes, the tools
need to be able to parse the nested hierarchy if we introduce it. it would be
nice to have the hierarchy support to keep the manual maintained i18n files
compact and easy editable.
bq. You could build a little preprocessor that would convert the nested
dictionaries into the plain json format for example, as part of build tooling.
this does already exist: http://wcm.io/tooling/maven/plugins/i18n-maven-plugin/
although this currently only produces the "old i18n format" with one node per
i18n key, it would be easy to add output for the flat json format.
but the problem is that this does not work together with mounting the
application source directory with Sling-Initial-Content with the file system
resource provider - the maven tool produced the flat json file in the target
folder, not in the source folder. but the file system resource provider mounts
the source folder, so there it finds only the nested json file.
> 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)
