[i18n] Internationalization

[kavilla]

Is your feature request related to a problem? Please describe.

The problem arises from: https://github.com/opensearch-project/OpenSearch-Dashboards/issues/772

Originally an internationalization plugin existed in a proprietary section of the legacy application. The plugin would host internationalized messages and formats for different locales in a JSON file and a call to /translations/{locale} would return that file. The application is already built out to handle i18n messages but doesn't have anything return for the locale provided.

Describe the solution you'd like

Create an i18n SERVER plugin (non-UI), that is not part of the OpenSearch Dashboards repo that returns the correct values from a provided locale under the route /translations.

Example response:

 {
    "locale": "zh-CN",
    "formats": {
      "number": {
        "currency": {
          "style": "currency"
        }
      },
    "messages": {
      "advancedSettings.advancedSettingsLabel": "石弟",  
    }
  }

Describe alternatives you've considered

The plugin could go into the Dashboards repo but that is just another thing the main repo will have to manage. If it is external it will be much easier to contribute translations.

Additional context

We name the plugin some form of i18n/l10n/internationalization/localization and not translation. Translation doesn't really seem correct since I wouldn't say "translating the currency".

We could also change the api call from the main repo to call an updated endpoint.

[kavilla]

Need list of translations

[ahopp]

Thanks for opening! If I understand, if a user wants to add a new language they would;

1. Open an issues the language they want in the internationalization/localization plugin
2. Someone would generate the translation (in the form of string to translated string JSON responses)
3. Someone would open a PR for the locale specific JSON
4. The plugin owner approves and merges
5. YAML is updated to reflect the language of choice (same as today)

I think that makes sense to me - we'll need to figure out how one goes approving a PR for a language they don't speak but I think that's more operational.

Long-term, we should consider creating a path for the end user to select the language preference of their choice so an Dashboard instance can be vended in multiple languages at the same time.

[joshuarrrr]

We've now created the i18n OpenSearch Dashboards plugin. @ahopp @kavilla, is there more work to be done for this issue?

[ananzh]

I think we could close the issue, since the plugin is released.