This would turn return <div>{t('my_translation_key')}</div>;
into return <div>My Translated Text</div>;
at compile time. (Well, the React transformer would also replace that JSX, but whatever.)
- Keeps the final JS bundle small
- Keeps a component's translations with the component so we don't have the translation overhead for components we don't need to load
- We can just use https://github.com/webpack-contrib/i18n-webpack-plugin out of the box
- Doesn't support PhraseApp's in-context editor unless we have an entirely separate bundle for the in-context editor that keeps each translation output as a function of the key.
- Doesn't allow for substring search and replacement for translating dynamic content.
This would keep return <div>{t('my_translation_key')}</div>;
the same but would statically analyze the
code and come up with a list of these calls. It would then figure out which keys the code is using and
only include those in the locale config that gets bundled with it.
- Keeps the translation small at first
- Doesn't change the logic for translation at all—just changes the json data that is included in the bundle.
- The translation data included in the bundle is small at first but will grow to include all translations as Angular components are replaced by React components.
- Would have to have it figure out what strings are used for translating dynamic content.
This would work similarly to the Translation Function with Selective Translations except that each file that uses the translation function would add its own translation keys to the translation function at compile time. For example, the translation function would start out using an empty config, and the bundled MyComponent.js
would have the following at the top:
t.extend({
my_translation_key: "Translated Text"
});
which would merge its translation key-value pairs to the translation function's config.
- Bundles translations with each component to reduce loading overhead
- Assumes implementation details. To make it less frankensteiny, we would probably want to make the webpack plugin include all of the translation function code instead of importing it from our own codebase.
- Controls logic for translation within the plugin instead of within the code, and if we left it up to the code, it would be too tightly coupled with the build/transform plugin.
- Would have to have it figure out what strings are used for translating dynamic content.