One fault line runs through all five angles: the runtime-resolver generation (react-i18next, react-intl) versus the compile-time cohort (Lingui, Paraglide, and next-intl’s ahead-of-time path). It is not just a bundle-size story. The same split decides type safety — compile-first libraries hand you typed keys and “missing key = build error” for free, while i18next bolts safety on through a hand-maintained d.ts module augmentation [1] — and it decides runtime fit: runtime resolvers need React context, so they fight Server Components, whereas next-intl and Lingui v5+ resolve translations on the server with no use client boundary [2][3].
The practical consequence is that “which library” is really “which pipeline.” The library pins your message syntax — full ICU in react-intl [4] versus i18next’s custom interpolation, with ICU only via a plugin [5] — your catalog format, and therefore your translation-management options: i18next leans on Locize/Crowdin/Phrase [6], Lingui commits you to gettext PO through Crowdin [7], and Paraglide ties you to the inlang ecosystem. Library and workflow are one decision, made once.
The angles also contradict each other, and that is the useful part. Paraglide wins bundle and type-safety decisively — a benchmark of 47 kB versus i18next’s 205 kB at 5 locales × 100 messages, staying flat as the catalog grows [8] (⭐ 567) — but loses on reach: no React Native adapter and the youngest project of the set. react-i18next wins ecosystem and TMS integration by an order of magnitude of downloads [9], yet ships the whole catalog to the client and types nothing by default. next-intl wins the Next.js App Router outright, but is Next-only and effectively single-maintainer [10] (⭐ 4.3k).
So the runtime, not taste, resolves it. On the Next.js App Router → next-intl. Need React Native, several frameworks, or a large existing team → react-i18next, the boring, universal default [11]. Greenfield web app where bundle and types lead → Lingui (the safe compile-time pick, automatic extraction) or Paraglide (the aggressive bet). Translators who live in ICU → react-intl. typesafe-i18n — the original typed-i18n idea — has stalled; prefer Paraglide for the same promise on a healthier project [12].
The one thing this run did not quantify is migration cost, and every source agrees a mid-project i18n switch is among the most painful frontend refactors [13] — which is exactly what makes the compile-time bet a bet. The open question that collapses most of the matrix above is upstream of any library: is the target a Vite SPA (→ Paraglide or react-i18next) or a Next.js App Router app (→ next-intl)?