UI translation

Server-side

Pages and components rendered on server-side (i.e. all the template-based output) are translated using Gettext. Translation files are located in locale directory.

Due to its WSGI nature, KonText cannot switch user's language by setting proper locale for the whole program (just like bonito-open does). For that reason KonText defines a custom, thread-local ugettext function (see lib/translations.py for details) initialized with current client language.

Date, time a number formatting is specified in *locale/[lang]/formats.json file and can be obtained via functions defined in lib/l10n.py.

Client-side

Plug-ins' views and new core views are translated in a different way. Messages are rather encoded using 'message-like'identifiers:

somePlugin__warn_user_should_not_leave --> You have an unsaved work. Do you really want to leave?

Moreover, these translations are performed on the client-side using format.js (to be more precise: intl-messageformat).

Translations of different parts of the application are expected to be stored in different files. Such file must be named messages.json and should be located in the same directory as respective views. E.g.:

public/files/js/plugins/myPlugin/init.ts
public/files/js/plugins/myPlugin/views.ts
public/files/js/plugins/myPlugin/messages.json

A detailed description of the file format can be found e.g. on intl-messageformat project page. KonText requires you to define translations in a JSON-compatible way (e.g. keys must be always double-quoted):

{
  "locale-code-1": {
    "key1": "Translated message",
    "key2": "Another translated message"
  },
  "locale-code-2": {
    "key1": "Translated message",
    "key2": "Another translated message"
  }
}

Deployed KonText uses a single messages file generated by its Grunt script which merges all the JSON objects and defines a single AMD module.