Skip to main content

i18next

What is i18next​

i18next is a framework-agnostic JavaScript internationalization library. Its official React integration is react-i18next. It is MIT licensed, currently at v25.x, with ~11.8M weekly npm downloads (core) and ~8.5k GitHub stars. It has 14+ years of active maintenance and built-in TypeScript support (TS v5+).

Why we recommend it​

  • Framework-agnostic — works with React, Vue, Angular, Node.js, and React Native. One i18n investment transfers across projects.
  • Massive, battle-tested ecosystem — i18next-http-backend for lazy-loading translations, i18next-browser-languagedetector for auto-detecting user language, and 50+ community plugins. Used in 473k+ repositories.
  • Plugin architecture — swap backends (HTTP, filesystem), language detectors, and formatters without changing application code.
  • Type-safe translation keys — full TypeScript support with typed t() calls that catch missing keys at compile time.
  • Production-grade features out of the box — CLDR-compliant pluralization, interpolation, namespaces, context-dependent translations, and fallback languages.
  • Fits the Aliz stack — pairs naturally with React + TypeScript + Vite via react-i18next.

Why over alternatives​

  • vs react-intl (FormatJS) — react-intl is ICU MessageFormat-first and React-only. i18next supports multiple frameworks, has a richer plugin ecosystem, and offers simpler syntax for common cases. Prefer react-intl only when strict ICU compliance is a hard requirement.
  • vs next-intl — next-intl is purpose-built for Next.js App Router and is the better fit for Next.js projects. For Vite-based React SPAs (the Aliz default), i18next is the right choice.
  • vs LinguiJS — LinguiJS extracts messages at compile time and produces smaller bundles, but has a smaller community and ecosystem. i18next's runtime model is more flexible for dynamic content and lazy loading.
  • vs Polyglot.js — Polyglot is tiny but effectively unmaintained. i18next covers everything Polyglot does and far more.

When to use​

  • React SPAs (Vite-based) that need multi-language support
  • Apps integrating with a Translation Management System (TMS) like Locize, Crowdin, or Phrase
  • Multi-platform projects sharing translations across web, React Native, and Node.js backends
  • Projects requiring lazy-loaded translations per language/namespace to keep the initial bundle small

When NOT to use​

  • Next.js App Router projects — prefer next-intl which is designed for Server Components and App Router conventions.
  • Single-language apps — adding i18n infrastructure has a cost; skip it if there's no plan to support a second language.
  • Strict ICU MessageFormat compliance — if the project or translation team requires full ICU syntax, react-intl (FormatJS) is a more natural fit (though i18next supports ICU via the i18next-icu plugin).
Key naming constraints

Translation keys must not contain : (namespace separator) or . (nesting separator) as literal characters. Choose these separators carefully at project start — changing them later requires renaming every key.

Resources​