Skip to content

Instantly share code, notes, and snippets.

@pwolfert
Last active April 17, 2017 21:02
Show Gist options
  • Save pwolfert/5450592eafa03cfa677e72a72bcdfe67 to your computer and use it in GitHub Desktop.
Save pwolfert/5450592eafa03cfa677e72a72bcdfe67 to your computer and use it in GitHub Desktop.
Translation Options

Translation Options

1. Bake in the Strings

Summary

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

Pros

Cons

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

2. Translation Function with Selective Translations

Summary

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.

Pros

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

Cons

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

3. Translation Function with Per-Component Translations

Summary

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.

Pros

  • Bundles translations with each component to reduce loading overhead

Cons

  • 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment