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:
- 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.
- 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.
- 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.
- Security - the current version of the library should not have known security issues.
- 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.
- 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.
- 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.
- 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:
|11 days ago
|13 days ago
|a month ago
|3 days ago
|2 months ago
|23 days ago
|3 years ago
|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
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
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.
|Well-structured and detailed documentation with examples using App Router and Pages Router
|Well-structured and detailed documentation, but examples are only described for React applications, requiring adaptation for Next.js.
|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.
|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.
|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.
|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, 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:
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
@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.
For further exploration, let's consider all four libraries:
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 will definitely support all our early users. Register through the link for free, and let's make localization no longer a headache for developers.