Drawbacks of other i18n solutions
Let's make the sample using our own base i18n framework i18next. Like all other solutions, some come with drawbacks. These will be highlighted after samples.
Using a pure javascript i18n framework
More react adapted "react-i18n"
The above is basically how every i18n framework for react works. The translations and language get set when initiated and a translation function is made available. You could easily extend this hiding the i18n.init inside a provider and pass down the function by context to another component to translate strings.
So let's make this more visible with some pseudo code:
The drawbacks
Before we come to the drawbacks let's highlight some advantages of those solutions above - they are very simple to get started.
Changing the language
Can you easily change the language? Get the translations in other language loaded? Does the language change trigger a rerender?
That's what the withTranslation higher order component or useTranslation hook do!
Scale and split your translations into multiple files
When your project gets bigger you do not only want code splitting but you also like to load translations on demand to avoid loading all translations upfront which would result in bad load times for your website.
With loading translations asynchronous there comes another problem - does your framework handle the pending state during loading translation?
That's what the withTranslation higher order component or useTranslation hook do!
Can you translate combined jsx nodes in one sentence
Let's take following content:
In most frameworks you will end having to split this into multiple translation strings. But for your translators it would make sense to have this as one sentence to translate like eg.:
You can do this using the Trans component.
Last updated