DEV Community

Discussion on: Setting Up Localization in your React App

Collapse
 
thesanjeevsharma profile image
Sanjeev Sharma

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?

Collapse
 
brense profile image
Rense Bakker

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.

Collapse
 
seancassiere profile image
Sean Cassiere

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.
Thread Thread
 
lwchkg profile image
WC Leung

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]
        ),
      };
    }
Enter fullscreen mode Exit fullscreen mode

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