At Connected Cars, we pride ourselves on being able to offer our customers a solution tailored to their needs. We allow for local integrations that made sense to our customers and offer the possibility of translating our products’ interface into the local language.
Translating our products into a different language every time we expand into a new country can easily become a cumbersome process. That is why our development team has worked on finding a translation setup that is effective and makes it easy to keep track of all needed translations.
Our current translation setup is based on gettext, which allows us to use string-based translations, as opposed to key-based. This means that instead of a vague key representative, we include the actual text string in our code. One of the benefits of doing this is that when the source text (which is in the code itself) is changed, it invalidates all the translations on the string which makes it easier to pinpoint exactly what needs to be updated and re-translated.
If you prefer key-based translations, it’s still possible to use them with this method as you could simply make an English translation of the source text.
The tools
Based on gettext we built a library currently called react-i18n which can be found on GitHub and NPM. The library includes our `import` and `export` scripts, as well as the functions that allow for translations.
The `export` script scans through all our source code, extracts the translations automatically, and builds a `.POT` file. Next, the `import`script takes all the translated `.PO` files and generates a `translation.json` file, which is used in the code for actual translations.
The process
During our build step, when code is merged into our master/release branch, the export script is run and it uploads the current source texts to Crowdin. This notifies all our translators that new translations are available and ready to be translated.
Once everything has been translated, we can then run our `import` script on the branch locally, which downloads all the translations from Crowdin and automatically creates a new pull request on Github with the new changes. This way, we can easily review it before it’s merged in and deployed to production.
Our translation setup in practice
Below is an example of how our translation setup works.
For a simple translation you simply do: `t(‘Activate vehicle’)`
Plurals are also supported, e.g. `t(selectedVehicles, ‘Activate vehicle’, ‘Activate {n} vehicles’)`. Languages with different plural rules such as Russian are also supported natively and will be prompted to translate accordingly in Crowdin/POEdit or whatever the preferred tool is. The `.PO` file generated will contain the plural rule code, which is then executed on runtime when plurals are rendered.
It’s also possible to do multi-line translations, or even “include” React in them as well. For example, you might have multiple paragraphs in a single translation, which might also have different formatting as well as links:
Hooks: `const { t } = useTranslate()`
HoC: `withTranslate(props => …)`
contextType on class components: `static contextType = I18nComponent`
Render props: `<I18nConsumer>{props => …}</I18nConsumer>`
If you want to see more examples and ways of using our translation setup, check out our repository.
