we will need to pull out ui text out of components into i18n files

[balmas]

we will need to pull out ui text out of components into i18n files

not an urgent priority but maybe something to do when we move components out of the extension into their own library

[kirlat]

Since we are probably interested in localizing messages that are shown via UI only, and all of the UI is implemented with Vue, I think it will be best to use a Vue localization plugin for that. The main benefit would be reactivity: UI will be updated automatically after a locale is changed.

Browser extension localization API (https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Internationalization) would be of not much help for us, I believe. First of all, it is tied to language preferences set in a browser configuration. Thus, there is no way to change a UI language without changing it in browser settings. I don't think changing it there is a viable in many cases:

• User is not using his/her own computer (i.e. Internet Cafe).
• User browser language preferences are not configured correctly and user does not know/care how to do that.
• For whatever reason user wants to use a UI language that is different from the one set in browser options.
  Second, it does not have much features. For example, plurals are not supported AFAIK.

There are several Vue.js i18n plugins to choose from (I omitted the ones that are not actively developed or requires special Vue modules such as Vuex):

• vue-intl (https://github.com/learningequality/vue-intl) is based on message.js. However, it was not updated for the long time and this is probably not safe to use.

• two i18next based plugins (https://github.com/rse/vue-i18next and https://github.com/panter/vue-i18next). The latter is more actively developed, but as it is i18next based, it shares all advantages and drawbacks with i18next. i18next ecosystem is extremely wide and has many plugins for different frameworks. However, i18next uses its own message format that is not near any standard and not plays well with localization community. It seems that i18next is not eager to adapt any standard-based solutions at the moment.

• vue-i18n (https://github.com/kazupon/vue-i18n) from a Vue.js core developer. Created from scratch for Vue, it provides a seamless integration and is the most actively developed among all Vue i18n plugins. Good thing is that it supports ECMA-402 and localization of single-file components (can be good for us if we ship components separately). It has a special Webpack loader. Below is some information about vue-i18n.

• In v7 it has an ECMA-402 standard (Intl.DateFormat and Intl.NumberFormat) support.

• Documentation: http://kazupon.github.io/vue-i18n/en/

• ICU format is not supported out of the box (no support among other Vue.js plugins too),
  but probably this can be done with a custom formatting
  (https://kazupon.github.io/vue-i18n/en/formatting.html#custom-formatting).

• It supports single file components with custom blocks and a webpack loader (https://github.com/kazupon/vue-i18n-loader)

• Locale can be switched dynamically: Set locale dynamically at runtime kazupon/vue-i18n#253

• Different images can be served dynamically: how solve different imgs in vue-i18n kazupon/vue-i18n#248

• Language resources can be loaded on the fly: http://digital-cult.com/vue-i18n-async-loading-languages/

What features would we need for i18n? In what way our i18n/l10n requirements may extend in the future?

[balmas]

this is great info. let's discuss.

[balmas]

Ok some basic requirements:

1. Separation of text and translations from code
2. Works with Vue components but also could be fairly easily ported to other frameworks if need be
3. Need to be able to localize messages and data as well as the UI elements. If we can use the same solution for all of these great, but if not, then we should use what is best for each.
4. dynamic locale switching
5. support for standard formats and language codes

I think the trickiest part of this might be knowing where the separation between data models and ui elements lies and finding a solution that makes sense across all of these.

For example, we have data coming back from the tufts-adapter that we map to Features which for which we use Constant strings to limit and normalize results. Those strings are currently in English, because our parsers output them in English. We probably would continue to normalize to English even if we have other parsers which use other languages, but then we may need to translate those strings for display, as well as extend them with abbreviations, extend them with captions, etc. (see my hack for gender abbreviations at https://github.com/alpheios-project/data-models/blob/master/src/i18n.js and https://github.com/alpheios-project/data-models/blob/master/src/feature.js#L80-L85 )

It would be nice to have a standard approach that worked across the entire ecosystem, but it might also be acceptable to have different approach for each distinct need (As long as those were used consistently).

[balmas]

@kirlat I like the approach taken in commits 99be95f and 6795062 . I think we should go with it for now, and we can begin to move messages over to it after the alpha release.

[balmas]

this is done for the ui text and messages. Will need to decide upon and implement a solution for the data and data providers still.