How to choose an i18n library for a Next.js 14 application - Part 1

What is the best choice, and how does one go about selecting an i18n library for production? Let's address this decision-making process.

In my previous post, I selected the Rosetta internationalization library to demonstrate how a multilingual Next.js application can be easily implemented. However, as correctly pointed out in the comments, it's not the optimal choice. I concur; Rosetta was last updated three years ago, making it a red flag for me not to use it in a production environment.

The article will consist of three parts:

• In the first part, I will discuss the criteria for selecting a library, form a list of libraries, compare them based on the criteria, and choose the three most suitable libraries for further analysis.
• In the second part, I will compare the functional capabilities of the libraries, identify commonalities and differences, and select two of them for testing.
• In the third part, I will test the chosen libraries and draw a conclusion about which one I would use for a productive environment.

Firstly, it is necessary to determine the criteria for a library suitable for production. Based on my own experience, I will highlight the following criteria:

1. Popularity and Rating - this is more about ensuring that many developers are familiar with the library, and there is a sufficient community to address emerging difficulties and problems.
2. Relevance - it is a red flag for me if the library has not been updated for years. This usually means that the library is not evolving and may not support the latest changes in Next.js. Even if everything currently works correctly, there is no guarantee that it won't break with the next Next.js update.
3. Presence of Quality Documentation and Examples - this is an important criterion as it allows for faster implementation of the library and significantly simplifies maintenance in the future.
4. Security - the current version of the library should not have known security issues.
5. Readable Source Code of the Library - the assessment of code cleanliness and readability will always be subjective. In most cases, this is not required, but it can be useful, especially when choosing a less popular and unsupported library at the moment. In this article, we will not consider such libraries, so we will not assess them based on this criterion.
6. Performance - it consists of two parts: the library's size and loading time, and the actual code execution speed in the library. We will try to evaluate this during the testing phase.
7. Functional Capabilities - the library should meet the functional requirements of the system to avoid searching for workarounds or having to change the library in the middle of development.
8. Adherence to Standards - I will strive to choose libraries for a productive environment that adhere to accepted standards. If necessary, I want to be able to replace one library with another with minimal effort.

In the first part of the article, we will select libraries and evaluate them based on the first four criteria. Using these criteria, we will choose three libraries for further analysis. In the second part, we will assess the chosen libraries based on criteria 7 and 8.

To begin, let's compile a list of available libraries and look on their popularity:

Disclaimer: This numbers are current as of November 27, 2023. Web development evolves rapidly, and within a few months, the landscape may have changed.

Next, we will not consider rosetta and next-localization as they have not been updated for more than two years, and as a result, they have the lowest number of downloads, which is constantly decreasing.

We will check the packages for known vulnerabilities using the Snyk CLI.

~$ snyk test next-intl@latest

Testing next-intl@latest...

Organization:      ***
Package manager:   npm
Open source:       yes
Project path:      next-intl@latest

✔ Tested next-intl@latest for known vulnerabilities, no vulnerable paths found.

After checking all packages, we find that all specified packages do not have any known vulnerabilities - excellent!

Now, let's take a look at the documentation.

Since we will be focusing on developing an application with Next.js 14, I did not evaluate next-i18next, and we will not consider this library further, as they recommend using react-i18next instead. We will also not consider the library next-translate as, in my opinion, its documentation does not appear to be up-to-date and convenient enough for easy and quick integration into our future system.

My personal choice unequivocally falls on next-intl as the most qualitatively documented and react-i18next as the most popular library.

Choosing a third option for further analysis seems more challenging, with two libraries competing: @lingui/react and react-intl. Both will require additional exploration to integrate into a Next.js 14 application. One is very popular, with over a million downloads per week, while the other has a more structured documentation.

Both of these libraries use approaches that are different from next-intl and react-i18next. @lingui/react uses an additional CLI for extracting translatable strings from page code, which, in my opinion, complicates the development process and makes it harder to abstract translations from the code. react-intl uses special javascript objects describing translatable messages.

For further exploration, let's consider all four libraries: next-intl, react-i18next, @lingui/react, and react-intl. We will try to compare their different approaches and the functional capabilities they provide.

If you use other libraries and are confident that they can compete with the ones selected, please let me know in the comments, and I will be sure to investigate them.

Subscribe for notifications not to miss the next parts.

While you're waiting for the next round.

We need your feedback about our recently launched Gitloc, a localization platform for modern web applications — an ideal choice for indie developers and small teams.

We invite you to test our system, which will only take 10-15 minutes. Follow the instructions in the previous article or check out documentation.

It is crucial for us to receive feedback from developers at this stage. You can leave your feedback in the comments to the latest release in our Telegram channel or write to feedback@gitloc.org.

We will definitely support all our early users. Register through the link for free, and let's make localization no longer a headache for developers.