Drawbacks of other i18n solutions
Last updated
Last updated
Let's make the sample using our own base i18n framework . Like all other solutions, some come with . These will be highlighted after samples.
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:
Before we come to the drawbacks let's highlight some advantages of those solutions above - they are very simple to get started.
Can you easily change the language? Get the translations in other language loaded? Does the language change trigger a rerender?
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?
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.:
That's what the higher order component or hook do!
That's what the higher order component or hook do!
You can do this using the .