i18N for Capacitor plugins.

As we have more capacitor plugins and also applications being developed for different locales, having a fixed set of string resource values will make the app not “accessible”

Normally, this is done using storing the localisation strings in the resource table in the native code. I am proposing that the strings be passed as an array during the initialisation of capacitor plugin.

Another issue is that for supporting multiple languages would require having to spend time on creating the resources, reviewing the correctness and committing the changes. This would make the whole process time consuming and lengthy.

I am submitting a RFC for this.

Proposal:

1. A general mechanism for app developers to provide an array of localized strings that 
would be passed during the plugin initialization. 

2. When a plugin dialog is displayed use the localized strings that were provided to
   give a better accessible user experience

3. In case a localization string is not available, fallback to the default 'EN' string.

3.1 In case string was missed, future version of software can have the support added
    or provide better localizations.

By having the app developer control over the localised strings it would help develop apps independently without having to depend on commit cycles of native plugin.

[sandstrom]

I’ll propose an alternative solution to this problem

As long as plugins make strings configurable (most have only a handful), the JS layer can use its existing localization solution (Ember, Angular, etc. all have mechanisms for localization already).

Conveniently, this is how most Capacitor plugins already work, for example:

import { Plugins } from '@capacitor/core';
const { Modals } = Plugins;

// en
Modals.confirm({
  title: 'Confirm',
  message: 'Are you sure you\'d like to press the red button?',
});

// with translation
Modals.confirm({
  title: this.get('locale').translate('modal.confirm'),
  message: this.get('locale').translate('modal.confirmBody'),
});
// `this.get('locale')` would be backed by e.g. ember-intl

Benefits

• Most plugins already support this, so little extra work.
• It’s very simple, plugin authors already know how to pass strings between JS and native layer.
• Can support any number of languages.
• Doesn’t need to be concerned about localization codes (EN vs. en-gb vs. eng).
• Works with any localization framework (Ember, Angular, Vue, etc).

Plugins that need to be updated

Here are some plugins that have some elements that aren’t configurable at the moment:

• https://capacitor.ionicframework.com/docs/apis/camera (https://github.com/ionic-team/capacitor/issues/2113#issuecomment-547927344)
• please add more items to this list if there are any

Way forward

1. Add paragraph under authoring plugins and mention that plugin authors should make any UI strings configurable, for localization support.
2. Update the (few) plugins that still have have some UI strings that aren’t configurable.
3. Capacitor is 100% localizable

Let me know what you think!

ping @jcesarmobile @xmano @TrayserCassa

[xmano]

I have some code changes for the proposal. It is a private repo though:

https://github.com/ionic-team/eauth-integ-test/commit/c9ef8405aa6969a46b3496f2b828bd0d99690b86

The idea is to pass a localise string array to the plugin initialisation code and have the platform render the strings properly when the UI is displayed.