Investigate Internationalization

[wycats]

Right now, validators produce a message. We could in principle have them produce an i18n key, but that wouldn't really be compatible with more robust i18n solutions like MessageFormat.

We should decide what format we need the message to be in to properly support various i18n solutions.

[wycats]

Reading material: https://messageformat.github.io/

[sohara]

Currently Copilot employs and Ember addon called called ember-i18n for i18n. So far it works well, but we've only i18n'd a small subset of the overall copy/ui (to say nothing of data) within the app.

I will just comment some questions here:

• The planned solution for translation services is Qordoba via its github integration: https://dev.qordoba.com/docs/about-gh. The intention for the first passes of translations is to use an automated system (machine learning-based, I am told). Would such a system support ICU/messageformat? I'm guessing not, since greping their docs yields no results, but I will inquire.
• For human translators (presuming non-engineers here), what is more ergonomic, an interpolated string format such as messageformat, or a nested object as used by https://github.com/jamesarosen/ember-i18n (the addon we currently employ)? Same question for engineers.
• Does https://github.com/ember-intl/ember-intl (the other competing addon in the space with the most traction confer other advantages that we would find useful?
• Is there a foreseen use case requiring translation of gender, where the gender of the term would be known at runtime? If so, we should heavily favour migrating to a lib that supports messageformat sooner than later.