I have a use case where I already have I18N dictionary in AEM and it is used to feed the translated labels to third party application.
Now I have a requirement to have versioned dictionary entries. The third party application needs to be supplied with version specific values for an I18N key if it asks for a specific version.
I am thinking of two solutions:
1. Customize the translator interface and add the ability to add version to a dictionary entry, may be a dropdown. If a version has been selected, the values are saved in custom property name like v8_sling:message instead of sling:message. The interface will reload the values if a version is selected. And then I can write an exporter to export the version specific dictionary.
2. Move to content fragments. Use the translation variations of content fragments and versions as well. Write the content fragment exporter for a specific version.
I'm not sure if I understand the purpose/value-add of this requirement correctly.
Would different versions have same key with a different value or a new key-value pair?
What is the end-goal to create this version?
Would you still have multiple versions available for your app to utilize and authors to edit?
The first solution may work but that might end up being a big effort. You have to find that is it worth the effort?
In the second solution, per my knowledge, multiple versions may not be available at any point in time although you could revert to an older version just like a page version. Is that a requirement? If not, then you could version it outside AEM in a source control.
You have understood it correctly. I need to support multiple versions at the same time. There will be calls from different versions of the 3rd party app for version specific dictionary entries. So we need all versions available at all the times.
If I push back the requirement for ability to edit the older versions, and maintain an versioned export on a periodic basis outside AEM as you suggested, it'll be a good solution to begin with.
What is the lifecycle of these i18n keys? Who is creating them and who is maintaining them?
In a typical AEM project i18n keys are created and maintained by developers, and typically deployed into AEM. They are not changing during runtime. If you choose this lifecycle as well, then you could also deploy these i18n keys directly to the consuming applications instead delivering them through AEM.
If you deliver these i18n data via AEM, there must be good reason for it. And my best assumption is, that these keys are maintained by developers and deployed, but instead the keys and translations are maintained by authors and changed at any time.