Discussion on: Setting Up Localization in your React App

View post

Replies for: 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 ...

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.

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":

    case "CHANGE_LOCALE": {
      return {
        ...state,
        strings: Object.assign(
          {},
          LOCALE_STRINGS[REGIONS.EN],
          LOCALE_STRINGS[action.payload.region]
        ),
        constants: Object.assign(
          {},
          LOCALE_STRINGS[REGIONS.EN],
          COUNTRY_CONSTANTS[action.payload.region]
        ),
      };
    }

For "smaller bundle size" the code depends on the packager used, so there's no point including the code here.