...

Message bundles for non-english texts

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)
  • on git, this would be, for example languages/french.git - which would contain N files.
  • These language bundles could be a module. They could thus be versioned, and have dependencies. Dependencies to module they translate would be marked as optional, but we would be able to maintain some sort of version-compatilbility between modules and translations - granted, that wouldn't be super simple to manage - where, for example, we'd update a dependency when keys have been added/removed from that dependency.
• 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)
• Need some sort of version handling - keep keys for older versions, add keys for newer ones ...
  
  • Chain (overlay) current translation file with older ones ?

...

• Enable inline translations within a dialog
  
  • I'm not sure the current proposal would work to enable inline translations. It'd be nice for translators to have at least a hint of what the key used for a specific item is. And if we somehow have elements explicitly use the KeyGenerator and other API methods for this, we might as well get rid of the proxy magic and use consistently... 
• Review process for in-house maintained translations as well as for contributed ones (currently relying on Google spreadsheet)
  
  • Have a Magnolia-hosted (or SaaS) 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
    • candidates so far: Transifex (am in contact with CEO Dimitris Glezos, who seems eager to help), Crowdin, WebTranslateIt, ... probably others.

Roadmap

• 5.1 : system in place, translations migrated for AdminCentral and most modules (DAM, STK, ...)
  • Module updates can be postponed
• ? : extract languages other than english into language-based bundles - needs a separate concept.
• ? : review processes for translating Magnolia, both internally and externally. Get contributions. With language files extracted from their modules, it might be easier. - needs a separate concept.

...