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: — 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. Popularity and Rating — 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. Relevance — this is an important criterion as it allows for faster implementation of the library and significantly simplifies maintenance in the future. Presence of Quality Documentation and Examples — the current version of the library should not have known security issues. Security — 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. Readable Source Code of the Library — 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. Performance — 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. Functional Capabilities — 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. Adherence to Standards 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: , weekly downloads 2.677.938, last updated 11 days ago react-i18next , weekly downloads 1.311.586, last updated 13 days ago react-intl , weekly downloads 350.234, last updated a month ago next-i18next , weekly downloads 118.061, last updated 3 days ago next-intl , weekly downloads 97.660, last updated 2 months ago @lingui/react m weekly downloads 73.427, last updated 23 days ago next-translate , weekly downloads 21.258, last updated 3 years ago rosetta , weekly downloads 14.404, last updated 2 years ago next-localization This numbers are current as of November 27, 2023. Web development evolves rapidly, and within a few months, the landscape may have changed. Disclaimer: Next, we will not consider and 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. rosetta next-localization 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. — well-structured and detailed documentation with examples using App Router and Pages Router next-intl — well-structured and detailed documentation, but examples are only described for React applications, requiring adaptation for Next.js @lingui/react — 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 react-i18next — 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 react-intl — 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 next-translate — single-page documentation, usage described only with Pages Router, recommends using react-i18next directly for Next.js 13/14 next-i18next Since we will be focusing on developing an application with Next.js 14, we will not consider further, as they recommend using instead. We will also not consider the library 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. next-i18next react-i18next next-translate My personal choice unequivocally falls on as the most qualitatively documented and as the most popular library. next-intl react-i18next Choosing a third option for further analysis seems more challenging, with two libraries competing: and . 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. @lingui/react react-intl Both of these libraries use approaches that are different from and . 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. uses special javascript objects describing translatable messages. next-intl react-i18next @lingui/react react-intl For further exploration, let’s consider all four libraries: , , , and . We will try to compare their different approaches and the functional capabilities they provide. next-intl react-i18next @lingui/react react-intl 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. about our recently launched , a localization platform for modern web applications — an ideal choice for indie developers and small teams. We need your feedback Gitloc 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 or write to . Telegram channel feedback@gitloc.org We will definitely support all our early users. , and let’s make localization no longer a headache for developers. Register through the link for free Also published . here

Too Long; Didn't Read

Making security fun one episode at a time

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

Too Long; Didn't Read

Arsenii Kozlov

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

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

Too Long; Didn't Read

Arsenii Kozlov

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES