Page Comparison

...

Translation of static GUI texts (author+publish)

• Status
  colour Green title 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

• Status
  colour Yellow title 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?

• Status
  colour Yellow title 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.?

Status
title Later

Translation of content

• 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