How can plugins provide their own language translations?

[cjthompson]

Overview

Currently, all translations are stored in a single JSON file (one per language). As the application grows, this file will become quite large and harder to manage.

In order to make our plugin architecture work (where all code is in src/plugins/[pluginName]), a plugin needs to be able to support translations.

Ideally, a plugin would not rely on translations to be included in the current global messages-??.json file.

Reference

See src/AppProviders.tsx for <I18n> component which defines the globally available translations

See src/assets/translations for all the existing translations and how they are exported

See src/plugins/index.tsx and src/plugins/cosmos/index.tsx for how plugins currently work

Options to discuss:

• Be able to split translations into separate files
• Have plugins provide their own translation files for their components
• Have plugins use their own translation files when rendering components

Some thoughts on possible implementations:

• Individual components could wrap themselves in an <I18n> component that loads just the translations needed for that component
• A plugin could wrap it's large pages (like Asset page) in it's own <I18n> component that loads from a plugin provided translation file
• A plugin could export in it's metadata (see plugins/index.tsx) used by PluginManager to "register" additional translations (Can we avoid naming conflicts? How?)

[LPX55]

The language files were restructured #1206 so that each language is in its subfolder. In all honesty, this was done to make the continuous localization play better with the current platform we are using -- but I did realize while making the change that this could be a potential solution to the plugin problem. As it currently stands, I am not too fond of the massive, repetitive, giant locale file that's been rolled up into one single keystore.

I'm not sure if its 'kosher' to have the locale files for the plugins in a completely different directory, but I don't see a huge problem with that approach. Plugin locale folders would follow the same structure as the actual plugins and components, all within each language. The platform will take care of syncing the locale keystores across all the languages.