Reputation: 26084
I am currently looking at various i18n npm packages and most seem to insist that the translations are stored in a flat file, e.g. .json formatted file. My questions is whether this has a performance overhead that would be greater then storing the languages in a database, e.g. MongoDB.
For example, if I have 10,000 translations (we will assume that in this particular application only one language file will be needed at a time, i.e. most will be using the application in English and some users may want to set the application to use a different language.) then this will equate to approximately 200kb of data to download before the application can even start being used. In a React application, a suggested design pattern is to load data using container components, that then pass data to 'dumb' child components. So, would it not make sense to also load translations in the same manner, i.e. group the translations into usage, or by component, so that the data is sent down the wire only when needed, say, from a call to MongoDB?
Upvotes: 1
Views: 3170
Reputation: 4498
If not yet done having a look at https://react.i18next.com/ might be a good advice. It is based on i18next: learn once - translate everywhere.
Your code will look something like:
<div>{t('simpleContent')}</div>
<Trans i18nKey="userMessagesUnread" count={count}>
Hello <strong title={t('nameTitle')}>{{name}}</strong>, you have {{count}} unread message. <Link to="/msgs">Go to messages</Link>.
</Trans>
Comes with samples for: - webpack - cra - expo.js - next.js - storybook integration - razzle - dat - ...
https://github.com/i18next/react-i18next/tree/master/example
Beside that you should also consider workflow during development and later for your translators -> https://www.youtube.com/watch?v=9NOzJhgmyQE
Upvotes: 0
Reputation: 556
I would integrate it in your API. That means you can create e.g. a REST or GraphQL API, which handles this for you. In i18n, it is often reasonable to store the data in a hierarchy. This means you can split your translations in different categories (like pages) and simply request those translations, which you really need.
I really like the way of doing it in the react-starter-kit. In this example, you find how they handle it with a GraphQL API and only request those translations, which are really required for rendering the page. Hope this helps.
Important files of the i18n implementation of the react-starter-kit:
Of course if you have this amount of translations, I would use a database for a better system usage (in the react starter kit, they use simple file storage which is not really usable with so many translations). A mongodb would be there my first choice, but maybe this is only my own preference of flexibility and own knowledge.
Upvotes: 1
Reputation: 773
Obviously, you don't want each and every language to be loaded on the client. My understanding of the pattern you described is to use a container component to load the relevant language for the whole app on startup.
When a user switches language, your container will load the relevant language file from the server.
This should work just fine for a small/medium app but has a drawback : you'll need another request to the server after the JS code has loaded to load the i18n data.
Another way to solve this is to use code splitting (and possibly server side rendering) techniques which could allow this workflow :
Upvotes: 0