How can plugins provide their own language translations? #1114
Replies: 1 comment
-
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. |
Beta Was this translation helpful? Give feedback.
-
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 translationsSee
src/assets/translations
for all the existing translations and how they are exportedSee
src/plugins/index.tsx
andsrc/plugins/cosmos/index.tsx
for how plugins currently workOptions to discuss:
Some thoughts on possible implementations:
<I18n>
component that loads just the translations needed for that component<I18n>
component that loads from a plugin provided translation fileplugins/index.tsx
) used by PluginManager to "register" additional translations (Can we avoid naming conflicts? How?)Beta Was this translation helpful? Give feedback.
All reactions