Capacitor: i18N for Capacitor plugins.

[xmano]

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.

[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.

[TrayserCassa]

Any Updates on that? Because it is very deep interaction with capacitor, so I didn't want to make a pull request and do it on my own. But my Product Owner sad, 'ionic is dead when they can't support local languages'.

[jcesarmobile]

Well, this only affects a few native messages on some plugins. Ionic apps can be totally localized except for those few native Capacitor plugins.

It’s still not clear if we will use some common json or if we will use the native implementation per platform.

As you said you thought about sending a PR, what would be your approach?

[TrayserCassa]

@jcesarmobile

It should be customizable over a File in the Project and not the native implementation. The cli could ask for a default language at the init function. The sync Function can then clone the data to the native string file.

The Problem with directly Native is, that I don't want to care about implementing it twice (Android, iOS). If you answer is, well we do it native, I will be writing my own cli for i18n Transfer.

[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

[SwenVogel]

Hi, is there any progress on this issue or maybe an workaround?

[jalison-dasilva]

Hi, is there any idea when this is gonna be done?

[sandstrom]

@SwenVogel and @jalison-dasilva Out of curiosity, would my proposal above work for your use-cases?

I.e. does the framework you are using (Ember, React, Vue, etc) have translation support built in or provided via an addon?

[jalison-dasilva]

Hi @sandstrom yes definitely the solution that you have proposed it would work for me.
I am using Angular here - so it would be fine.
Using the Camera plugin.

[jcesarmobile]

the user provided strings approach has been implemented for Camera plugin on https://github.com/ionic-team/capacitor/pull/2631

[sandstrom]

awesome @jcesarmobile!

I think you should close this issue + add a note in the docs about your approach to i18n in plugins:

For internationalization and localization (i18n) of your app, use the libraries and
tools available to the framework you are using. For example, React, Angular, Ember, Vue and
others all have very capable tooling around localization.
In Capacitor, all official plugins have configuration options for any strings visible in the UI.
That makes it easy for you to plug Capacitor into your existing localization solution.

[sandstrom]

@jcesarmobile For 3.x, maybe you can reconsider my suggestion about localization above? As the Capacitor-endorsed method of handling localization under 3.x plugins.

https://github.com/ionic-team/capacitor/issues/872#issuecomment-548047623

[dwieeb]

Thanks @sandstrom. I'll close this. I created https://github.com/ionic-team/capacitor-site/issues/95 to update the docs. If we're missing configuration options for strings in the official plugins now or in the future, for some reason, please open an issue in the plugins repo for Capacitor 3.