...

• Keys deduction is ok
• N2B will not work
  
  • can't really get the parent into the object (children objects are instanciated first) - not without modifying usage code (ie in setLabel() { label.setParent(this) }, which would suck)
  • can't really transform single properties other than with beanutils, which has even less notion of context, and whose usage is currently hardcoded in core 
• Proxy definition objects ?
  • I18nText will need some sort of context, the definition objects are not enough, since they don't know about user language etc.
• Basename could also be defined in site definitions (for in-template translations)
• Bundle languages in separate jars
  
  • english/master language still bundled with each module, other languages bundled in 1 jar (1 jar per language, containing translations for many modules)
  • maintenance is somewhat easier
  • but at the same time we might get "dependency" issues when modules add/remove keys
  • if we have tools for migration/validation of existing translations, the same tools could be used, perhaps as a maven plugin or sthg.
    
    • such a tool could potentially help enforcing compatibility between versions (i.e keep a key that was removed in version X+1 of module M)
• Ideas of supporting things like some.key=${some.other.key} 
  
  • mention of the CZ issue where in english a translation would be the same in 10 place but needs to be adapted in czech.
    
    • somewhat moderate issue with the mechanism is only supported with the same file
  • sorta conflict with the deduction of keys (you would use the most "low" common key for all those same translations)
    
    • makes the CZ problem perhaps more difficult, since the translator then can't rely on keys being defined in the english file
• Is basename actually needed ? Keys are long and unique
  
  • Global chains of message bundles - look into all known bundles
  • Basename helps grouping translation work - "I am now translating module X" - but that doesn't mean the basename has to be specified necessarily
  • Order of message bundles chain would need to be consistent and predictable
• Enable inline translations within a dialog
• Have a Magnolia-hosted tool to replace the google spreadsheet
  
  • some rules like "a translation needs to be validated by 2 other persons to be applied", "once applied it can't be changed directly - only via a 'request'", ...
  • could have a "MessagesManager" impl that fetches translations from this service

Done

Jozef did some work on this topic in the ui-translation branch. See git log master..ui-translation for details.

Suggestions

Differentiate between in-code-translations, vs in-config-translations. Translations in-configuration will require very little code change, but will require some work on update tasks and bootstrap files. IntelliJ (Eclipse too, probably) provides analysis tools to find out where i18n strings have been hardcoded. Attached a sample report executed on a couple of modules: i18-analysis.zip (main, ui, activation, cache, imaging, workflow). Note that the html-exported report is not very useable, but the in-app report is much more practical: Screen Shot 2013-07-31 at 14.21.14.png

...