[
https://issues.apache.org/jira/browse/SLING-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15997693#comment-15997693
]
Alexander Klimetschek commented on SLING-6826:
----------------------------------------------
This means the nested structure maps to aggregated keys like
{{application1.section1.component1.key1}} (mentioned in the description above,
but I somehow missed it).
Is having a plain json dictionary like this instead not feasible?
{code}
{
"application1.section1.component1.key1": "value1",
"application1.section1.component1.key2": "value2"
}
{code}
I'd be a bit hesitant to add a feature that is json format specific and not
really supported by other dictionary formats (e.g. the old sling:Message
structure, or even other like XLIFF). It could lead to some incompatibilities
at some point, and keeping it simple at the sling i18n side might be better.
You could build a little preprocessor that would convert the nested
dictionaries into the plain json format for example, as part of build tooling.
{quote}whenever the english text changes (for whatever reason), the key
contract is broken and all translations have to be touched as well{quote}
Note that this is a good thing, as when you change the original english text,
you usually need to change the translation or at least review it. The clearly
missing key/translation makes this detectable.
{quote}it is not possible to "namespace" i18n keys to separate different
applications deployed by different parties on the same instance{quote}
Yes, it is possible using comments. The convention we use in AEM is {{message
((comment))}} as key, and we have tooling around it (i.e. an API that supports
comments and our translation tooling can handle it and generate the right json
dictionaries in the end). Then you can have e.g.
* {{Share ((action button in main toolbar))}}
* {{Share ((link to the collaboration area))}}
Another option is to use the [basename
support|https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names],
where each dictionary has its own basename and you request the a specific
ResourceBundle at runtime,
> 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)
