next-intl contro react-i18next contro Lingui: quale usare nel 2026

Per un progetto Next.js con App Router, usa next-intl. Per una SPA React o per qualcosa che potrebbe superare i confini di un singolo framework, usa react-i18next. Se per te l’estrazione a compile time e i bundle leggeri contano più delle dimensioni dell’ecosistema, usa Lingui. Tutte e tre sono librerie i18n runtime: servono le traduzioni ai tuoi componenti, ma nessuna scrive le chiavi o i file locale al posto tuo. globalize.now è un’infrastruttura di localizzazione basata su IA che genera queste chiavi e questi cataloghi dalla tua codebase e funziona con tutte e tre le librerie.

Che cosa fanno davvero queste tre librerie?

Risolvono tutte lo stesso problema di runtime: data una chiave e una locale, restituiscono la stringa corretta, con plurale e formattazione appropriati. Questo include interpolazione, formattazione di date e numeri e regole di plurale tramite messaggi in stile ICU.

Nessuna delle tre produce le traduzioni. Una libreria runtime consuma un catalogo già esistente. Qualcuno deve comunque trovare ogni stringa visibile agli utenti nei componenti, sostituirla con una chiave e compilare un file locale per ogni lingua. È un livello distinto dello stack, e tenere separati i due livelli è il modo più rapido per capire il confronto: sceglierai esattamente una libreria runtime, che non è in competizione con gli strumenti che riempiono i suoi cataloghi. La nostra documentazione per sviluppatori descrive questa separazione in maggiore dettaglio.

Quando dovresti usare next-intl?

Quando usi Next.js con App Router. next-intl è l’unica delle tre librerie progettata attorno alle primitive dell’App Router: Server Components asincroni, navigazione consapevole della locale, helper per il routing e API per i metadati. A settembre 2026 è alla versione 4 e registra circa cinque milioni di download npm a settimana, il che la rende di fatto la scelta predefinita per i nuovi progetti Next.js, non solo in teoria.

I messaggi usano ICU MessageFormat, quindi plurali, genere e interpolazione seguono lo stesso standard adottato dal resto del settore. Se la sintassi ICU è nuova per te, abbiamo scritto una guida a ICU MessageFormat in linguaggio semplice. Il compromesso è il coupling: next-intl è una libreria Next.js. Se abbandoni Next.js, devi migrare anche il tuo livello i18n.

Quando dovresti usare react-i18next?

Quando non usi Next.js o vuoi avere alle spalle l’ecosistema più ampio. react-i18next è il binding React per i18next e, con circa quattordici milioni di download npm a settimana, è di gran lunga la libreria i18n React più usata. Il core di i18next è mantenuto da oltre un decennio e dispone di plugin per quasi tutto: backend che caricano i cataloghi via HTTP, rilevatori della lingua, livelli di caching e binding per framework oltre a React.

È la libreria scelta più spesso per impostazione predefinita dagli strumenti di coding basati su IA. Chiedi a Cursor o Lovable di «aggiungere le traduzioni» a un’app Vite + React e quasi sempre otterrai una configurazione i18next. È una scelta ragionevole: funziona ovunque e il suo formato di catalogo JSON è la cosa più vicina a una lingua franca dell’ecosistema. Il compromesso è che precede i Server Components, quindi con App Router richiede più configurazione di next-intl e gran parte del lavoro di traduzione avviene sul client, a meno di predisporre diversamente l’architettura.

Quando Lingui è la scelta giusta?

Quando la priorità sono le dimensioni del bundle e l’ergonomia del codice sorgente. Lingui, alla versione principale 6 a settembre 2026, adotta un approccio compiler-first: scrivi i messaggi inline con le macro e la sua CLI li estrae nei cataloghi al momento della build. I cataloghi compilati vengono distribuiti senza il sovraccarico del parsing a runtime, mantenendo basso il costo di i18n nel bundle.

Lingui usa inoltre i file PO di gettext come formato standard per i cataloghi, un formato che i traduttori professionisti gestiscono da decenni. I download settimanali sono circa un milione e mezzo, un ordine di grandezza sotto react-i18next: aspettati quindi meno risposte su Stack Overflow e meno plugin di terze parti. Funziona in generale con React, non solo con Next.js, ma come react-i18next non è costruita attorno alle primitive dell’App Router come next-intl.

Come si confrontano a colpo d’occhio?

Quale scegliere per una codebase generata dall’IA?

Scegli in base al framework, come sopra, ma tieni presente che la scelta della libreria non è il punto in cui le app costruite con IA sbagliano. Cursor, Claude Code e Lovable producono per impostazione predefinita stringhe inglesi hardcoded, qualunque libreria i18n sia installata, e un agent che modifica un componente continuerà ad aggiungerne anche dopo la configurazione della libreria.

La sequenza corretta è quindi questa: scegli la libreria runtime richiesta dal tuo framework, poi tratta l’estrazione e la manutenzione dei cataloghi come un problema separato. Per il caso Next.js abbiamo documentato la configurazione completa in aggiungere i18n a un’app Next.js creata con Cursor, mentre la pagina sull’integrazione con Next.js spiega come globalize.now prepara chiavi e file locale per next-intl prima di qualsiasi configurazione runtime.

Ti serve ancora un’infrastruttura di localizzazione se hai una libreria runtime?

Sì, perché la libreria legge soltanto i cataloghi: produrli e mantenerli è la parte che ti porta via tempo. globalize.now opera a quel livello: connetti il repository e converte la codebase una volta, sostituendo le stringhe hardcoded con chiavi e generando i file locale. Dopo questa conversione iniziale, i job eseguiti al push traducono le nuove voci di catalogo introdotte dai tuoi commit.

L’output è JSON o PO — JSON per le configurazioni next-intl e i18next, PO per il formato nativo di Lingui — così i cataloghi arrivano nel formato che la tua libreria runtime già consuma. Se la tua app ha già una configurazione i18n parziale, viene gestita anche quella: globalize.now funziona con i18n esistente invece di sostituirlo. Piani e tariffe d’uso sono disponibili nella pagina dei prezzi.

Nessuna delle tre librerie è una scelta sbagliata. next-intl se usi App Router, react-i18next se vuoi il massimo dell’ecosistema, Lingui se vuoi estrazione a compile time e cataloghi PO. Scegline una, tieni le stringhe fuori dai componenti e lascia che il livello dei cataloghi faccia il resto.