At my last job, we were using react i18n, but I found it hard. It could be because I didn't do the initial setup for it and I was still a beginner at react.
Anyway, my current job has a custom setup similar to what I have shared here(has much more helper methods and components). Do you see any potential problems with this? Or in what ways react i18n could be more useful that we are convinced to get rid of our custom implementation?
In the short term no, but in the long term, react i18n offers a lot of additional features that are a lot of work to implement yourself. I highly recommend learning it, i18n skills also transfer to other frameworks as well and it will be easier to connect with external translation software that have an option to export to i18n format.
For me, I'd personally use react-i18n because of the following:
Smaller bundle-size: As I wouldn't need to import all the translation files at build, and can load them as and when I need them. This is aside from Namespaces.
Fallbacks: Since, the JSON files are being loaded in directly into state, you aren't dealing with the use-case when a key is missing. Like if string.heading didn't exist in the ru.json file, then the app would crash. This, is not the case with i18n where it'd simply pull-up the key from the main/primary json file.
Intl support: i18n's built-in Intl API is great for stuff like number formatting and additonal region specific localization.
At my last job, we were using react i18n, but I found it hard. It could be because I didn't do the initial setup for it and I was still a beginner at react.
Anyway, my current job has a custom setup similar to what I have shared here(has much more helper methods and components). Do you see any potential problems with this? Or in what ways react i18n could be more useful that we are convinced to get rid of our custom implementation?
In the short term no, but in the long term, react i18n offers a lot of additional features that are a lot of work to implement yourself. I highly recommend learning it, i18n skills also transfer to other frameworks as well and it will be easier to connect with external translation software that have an option to export to i18n format.
For me, I'd personally use react-i18n because of the following:
string.heading
didn't exist in theru.json
file, then the app would crash. This, is not the case with i18n where it'd simply pull-up the key from the main/primary json file.Intl API
is great for stuff like number formatting and additonal region specific localization.Speaking for Sanjeev: I believe that it is possible to have what you've said "smaller bundle-size" and "fallbacks" with some minor change in the code.
Here's my change for "fallbacks":
For "smaller bundle size" the code depends on the packager used, so there's no point including the code here.