I18n support

Content Integration Framework makes use of localized messages wherever applicable & possible. It implicitly looks for localized strings in certain cases. It expects certain standard keys to be present inside translation files. Likewise, it provides an API to explicitly obtain localized messages inside service implementation should there be such need.

I18n support is provided to the plugins by means of translation (properties) files. Plugins can maintain the translation files inside src/main/resource/i18n directory. Alternatively, i18n directory containing translation files can be kept under classpath on the application server. Translation files must be named in the following format – {SystemId}_Messages_{locale}.properties. For example, for a system with Foo as an identifier, following sort of translation files can be placed inside i18n directory:
  • Foo_Messages.properties (default)
  • Foo_Messages_de.properties
  • Foo_Messages_en.properties
  • Foo_Messages_es.properties
  • Foo_Messages_fr.properties
  • Foo_Messages_it.properties
  • Foo_Messages_ja.properties
  • Foo_Messages_ko.properties
  • Foo_Messages_pt.properties
  • Foo_Messages_ru.properties
  • Foo_Messages_zh_CN.properties
  • Foo_Messages_zh_TW.properties

Not all translation files are mandatory. Content Integration Framework looks for the properties file corresponding to the user locale. If it does not find the translation in that file, or the file itself is not present, then it falls back to the file corresponding to the system’s locale. If no translation is found in this case as well (or the file itself is not found), then it falls back to the default translation file, Foo_Messages.properties. If the translation is found nowhere (either because of missing entry or missing file), then it uses the text appropriate for the given context. asset-integration-starter project is shipped with these sample translation files inside src/main/resources/i18n directory.