Internationalization

Owned by Stefan Seifert
Last updated: Sept 22, 2017
2 min read

Translation of static GUI texts (author+publish)

(tick) 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

(error) we stick with the built-in features of AEM