/
Internationalization

Internationalization

Sept 22, 2017

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.
Recently also https://docs.adobe.com/docs/en/aem/6-3/develop/components/i18n/i18n-extract.html was published.
To support our old hierarchical JSON files we have http://wcm.io/tooling/maven/plugins/i18n-maven-plugin/

  • 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/

    • 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

  • 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.?

Later Translation of content

we stick with the built-in features of AEM