Default implementation is storage in sling:Message nodes in the repository.
This is not very efficient from a repository point of view - huge number of small nodes, huge number of nodes below a single parent node. A query for select * from [sling:Message] in plain CQ6 instance results in >133.000 nodes (and crashes your browser in CRX DE Lite)
We can think about using an alternative storage mechanism for the i18n message, but still integration with sling i18n mechanisms
The goal is to use the built-in i18n "apply" mechanisms for
Dialog infrastructure/Granite UI environment
Sightly templates
Java Code
This includes support for placeholders in i18n texts that are replaced when inserting them
LATER Propably we will not support these features any longer:
Wiki-style markup in i18n translations
Support for wiki-style markup for simple formattings like line breaks, bold, italic, links
Support for formatters that convert this wiki-style to different output formats
Build full key based on context (java class name, JSP/Sightly script path), and use only local key in the sources
Support default definition of those local keys higher up in the hierarchy to define shared translations
New feature requests:
Automatic generate a list of constants from the list of i18n keys for referencing in java code (not so helpful in script languages like sightly)
Helper methods for getting subsets of i18n translation as dictionaries - e.g. as input for frontend-related translations e.g. in handlebars
Convenience support for automatically extend i18n keys with application namespaces? - or make use of "hint" as lookup key?
Helper tools
Automatically build i18n master key/translation files based on existing dialog definitions
This could perhaps be extended to parsing java and sightly code as well
I18n overlay mode
Allows to override i18n keys for a specific site (not only language) - or can this be mapped by translations per LANG_COUNTRY codes in CQ translator? And make sure the translations are not overwritten on re-deployment?
Allows to download the overlayed keys for translation - using a standard format like XLIFF would be helpful
i18n debug Mode to see which i18n keys are used where
This could perhaps be extended to support other data sources as well, e.g. content resource, backend data field etc.?
Translation of content
we stick with the built-in features of AEM
Primary goal: Use translation APIs already built into CQ
We need to do some research what is currently possible with CQ-builtin features and APIs, and what external providers like translations.com can provide
We stick with the built-in features of AEM - there was some improvements e.g. directly supporting efficient JSON files for translations in Sling/AEM.
we stick with the built-in features of AEM