What to Consider When Choose an I18n Library for a Next.js 14 Application

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:

1. react-i18next, weekly downloads 2.677.938, last updated 11 days ago
2. react-intl, weekly downloads 1.311.586, last updated 13 days ago
3. next-i18next, weekly downloads 350.234, last updated a month ago
4. next-intl, weekly downloads 118.061, last updated 3 days ago
5. @lingui/react, weekly downloads 97.660, last updated 2 months ago
6. next-translatem weekly downloads 73.427, last updated 23 days ago
7. rosetta, weekly downloads 21.258, last updated 3 years ago
8. next-localization, weekly downloads 14.404, last updated 2 years ago

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.

1. next-intl — well-structured and detailed documentation with examples using App Router and Pages Router
2. @lingui/react — well-structured and detailed documentation, but examples are only described for React applications, requiring adaptation for Next.js
3. react-i18next — detailed documentation, but in my opinion, poorly structured and overloaded with irrelevant information. Integration example for Next.js leads to a page outside the library documentation
4. react-intl — detailed documentation on the library and its API, lacking examples of using the library in an application. The documentation is oriented towards React, and adapting the library for use in a Next.js application is required
5. next-translate — detailed single-page documentation with a table of contents, improving navigation. Documentation refers to Next.js version 10, which seems outdated. All examples use Pages Router
6. next-i18next — single-page documentation, usage described only with Pages Router, recommends using react-i18next directly for Next.js 13/14

Since we will be focusing on developing an application with Next.js 14, we will not consider next-i18next 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, 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 [email protected].

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.