What you should know about the i18n support in Node.js v20

Internationalization support in Node.js refers to the ability of Node.js to support the cultural and socio-linguistic preferences of all international users. Here are some key points to note about Internationalization support in Node.js 20:

Node.js has many features that make it easier to write internationalized programs. Some of them are:
- Locale-sensitive or Unicode-aware functions in the ECMAScript Language Specification.
- All functionality described in the ECMAScript Internationalization API Specification (aka ECMA-402).
- Intl object.
- Locale-sensitive methods like String.prototype.localeCompare() and Date.prototype.toLocaleString().
- The WHATWG URL parser's internationalized domain names (IDNs) support.
Node.js and the underlying V8 engine use International Components for Unicode (ICU) to implement these features in native C/C++ code. The full ICU data set is provided by Node.js by default. However, due to the size of the ICU data file, several options are provided for customizing the ICU data set either when building or running Node.js.
To verify that ICU is enabled at all (system-icu, small-icu, or full-icu), simply checking the existence of Intl should suffice:
```
const hasICU = typeof Intl === 'object';
```
Alternatively, checking for process.versions.icu, a property defined only when ICU is enabled, works too:
```
const hasICU = typeof process.versions.icu === 'string';
```

To check for support for a non-English locale (i.e. full-icu or system-icu), Intl.DateTimeFormat can be a good distinguishing factor:

const hasFullICU = (() => {
try {
  const january = new Date(9e8);
  const spanish = new Intl.DateTimeFormat('es', { month: 'long' });
  return spanish.format(january) === 'enero';
} catch (err) {
  return false;
}
})();

The Node.js i18n Working Group is dedicated to the support and improvement of both Internationalization (i18n) within the Node.js project. This Working Group serves as a function of the Technical Steering Committee (TSC).
The implementation of i18n support including ECMA-402 within Node.js is one of the responsibilities of the i18n Working Group. The group is also responsible for ensuring Node.js is compliant with common standards such as Unicode, CLDR, and harmonized with other globalization efforts.
The ability for Node.js to effectively support the cultural & socio-linguistic preferences of all international users is maintained through Unicode processing and related services to support text written in all human languages, APIs and implementations which support the specific cultural & socio-linguistic preferences, such as localized methods for displaying dates & times, and the ability for Node.js and its related modules & applications to be translated into distinct human languages.
To implement Internationalization and localization in Node.js, there are different approaches available. Some of the popular ones include using the built-in Intl object, using third-party libraries like i18n, and using localization management platforms like Crowdin.
The Node.js Community Committee has a new i18n Working Group that gathers and supports Node's translation base. This consists of current l10n groups, independent translators, and hired translators (if a strategic initiative’s priority ever necessitates that). The translation base utilizes Crowdin localization projects for their work. The projects are born by statistical need and community desire. The work in Crowdin l10n projects generates automated PRs & updates to the Node.js i18n repo. The Node.js i18n repo exports one large JSON object, containing all site, docs, tutorial content, and helpful text in Node.js core–translated into every language. The i18n module is imported and used wherever it’s needed by Node.js to implement strategic initiatives.

Sources:

MarkoCen / markocen.com

What you should know about the i18n support in Node.js v20 #28