Translation of static GUI texts (author+publish)
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
- PRIO 1 Support CQ/Sling built-in i18n mechanisms
- 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
- Benefit of using the storage in repository: The built-in translator tool incl. XLIFF import/export can be used: http://localhost:4502/libs/cq/i18n/translator.html, http://labs.sixdimensions.com/blog/2012-05-25/adobe-cq5-translator/
- 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
- 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
- Default implementation is storage in sling:Message nodes in the repository.
- 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
- Wiki-style markup in i18n translations
- PRIO 2 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?
- PRIO 2 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.?
- Automatically build i18n master key/translation files based on existing dialog definitions
LATER 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
- A talk from AEMHub 2014 on this topic: http://de.slideshare.net/AEMHub2014/aem-hub-aem-g-lobalization-platform-v3-final