Comparing JavaScript internationalization libraries: A taste test
My foray into @angular/localize, i18next, and FormatJS.
Intro
Coding frameworks powered by JavaScript are used for mobile, web apps, and websites. However, JavaScript does not have a built-in library for localization. It can't dynamically translate date, number, or currency formats on its own, nor does it have a simple way to swap hardcoded text with their translated equivalent. That's why JavaScript i18n libraries exist.
There are more than a few JavaScript i18n libraries available to developers just like there are multiple JavaScript front-end frameworks. React, Angular, and Vue.js are the most used. So I set out to implement three i18n libraries, one for each framework.
Frameworks and libraries
My goal was to use a unique library for each framework but for various reasons I ended up trying two libraries on React and one library on Angular. For React I used i18next and FormatJS. For Angular I used its first-party i18n library @angular/localize.
I would like to make it clear that I am not a developer. I am a localization professional with experience in project management and solutions engineering, but not in coding or development. My coding inexperience prevented me from achieving my goal, but not from learning.
The assets I used
To use each i18n library I needed three functioning web apps, so I began by finding working projects by real developers. Two of the assets I chose came from GitHub and the other I created myself by following an online tutorial. I taught myself how to use the libraries by following a combination of blog posts and videos. Lokalise's and Phrase's blogs were invaluable for me.
Those assets are:
See the results of my efforts in this quick video!
Link to download zip files of my two projects:
Type-Master: https://drive.google.com/file/d/1kABGscd9nlES8KYkE2tQ7mZd8hNf1UqF/view?usp=sharing
Azcadea: https://drive.google.com/file/d/1Ipb9LuTbyU49SA4-9Zcg4CaLrzBMDmCx/view?usp=sharing
Challenges
I had difficulties finding assets that were not outdated. Coding frameworks evolve quickly. Projects from a year ago can rely on dependencies and libraries that are now deprecated or abandoned. Many of the assets and blog posts I attempted to use and follow were outdated and the libraries and dependencies the code used were deprecated or no longer functioned. That was the case for a Phrase tutorial on Vue.js and vue-i18n, and what prevented me from localizing a Vue project. The same can be said about tutorials and guides for internationalization. Many of the tutorials I found are more than a year old.
My coding inexperience was also a road block and it prevented me from localizing a React app with react-intl (FormatJS). Despite following the guide step by step, my IDE behaved differently than his and my locally hosted React app would turn white whenever I tried injecting a string with the proper syntax {t("key")}. I still don't understand why it happened.
Lessons Learned
Each i18n library has strengths and weaknesses, and before choosing the best one for your project take into consideration the following: quality of documentation, available support, and the frequency of maintenance and updates. You want your internationalized code to work into the foreseeable future and scale with your product, so look into the library's stability and popularity.
When establishing technical requirements look into each library's bundle size, message extraction, localization resource file types, 3rd-party plugins for the library, and locale switching. A consideration I found interesting is that @angular/localize does not support lazy loading and requires the localized versions to be rebuilt. When a user switches locales the entire app is reserved to them in that target locale.
I'd write all the considerations in detail but there is no point in reinventing the wheel. Check out the Lokalise and Phrase blogs for detailed info for each library.