full localization support

[lc-thomasberger]

currently the AT UI can't be fully localized. The AT displays text stored in the plugins properties schema files with do not support different languages yet.

Tasks for a fully localized UI:

add language picker to the AT [AuthoringTool]

currently it falls back to "en" https://github.com/adaptlearning/adapt_authoring/blob/master/frontend/src/core/app/app.js#L74

localizing Adapt Authoring GUI [AuthoringTool]

make sure all text displayed to users is set with polyglot.t("hello");

localize plugins schema files used by the AT [Framework]

• update plugins to support different languages
• one properties.schema
• subfolder containing language file (one for each language)
• AT compiles properties files in target langauges and stores them
• update AT to use different language based on user configuration

examples

"_isRandom": {
      "type":"boolean",
      "required":false,
      "default": false,
      "title": "i18n:_isRandom.title",
      "inputType": {"type": "Boolean", "options": [true, false]},
      "validators": [],
      "help": "i18n:_isRandom.help",
      "translatable": false
    }

{
  "i18n:_isRandom.title": "Randomised Items",
  "i18n:_isRandom.help": "If set to 'true', all items will be randomised"
}

open quesiton:

handle mongoose schemas stored in /plugins/content/*/model.schema https://github.com/adaptlearning/adapt_authoring/blob/master/plugins/content/article/model.schema#L20

suggesiton: Move them into the Framework and use them like "normal" property schemas?

[taylortom]

All sounds sensible to me.

I think we could do with abstracting the language layer too (i.e. your idea of using something like i18n) in case we ever want to move away from using polyglot.

We'll have to alter the way that language strings work at the moment slightly to allow the UI to make use of any plugins that are uploaded while the tool is running. Side-note: would also be good to have a nice way to add/install new languages -- possibly while the AT is running.

The selector itself can probably go on the user profile page.

[brian-learningpool]

+1

The selector could be defaulted on install (if we ever get other contributions other than English).

Polyglot is quite versatile and has served us well, but I agree that it could be abstracted out into a helper function.

In the front-end, there is a t() in helpers.jsalready, it could be a case that it's just not used everywhere. Of course we'll require something similar for the server-side.

In terms of adding languages, uploading plugins while the site is running, etc, this is something we need to look into, i.e. triggering that an updated version of the JSON is available.

[lc-thomasberger]

Thanks for the feedback guys! This is highly appreciated!

LearnChamp would like to contribute a German language pack for the Authoring Tool and all the Frameworks core plugins.

Setting the default language on install would be very nice. (Interesting Feature from an System Admin point of view)

+1 for having the selector on the user profile page.

A way to install language packs would be nice. We will need a way to check language packs tough and add a good way to handle missing translations. Should we store language packs (for the AT) in its own git repository and have a way to register them somewhere?

[lc-thomasberger]

Check compatibility issues using older versions of the framework that do not use the updated schema files with the Authoring Tool. Ensure backwards compatibility or prompt users to upgrade framework version?

[taylortom]

@jpablo128 has requested support for country-specific language codes (i.e. en_us, en_uk, es_es, es_ar) to allow for different variants of the same language.

[wojsmol]

Any plans to implement this?