Creazione:2025-01-02Ultimo aggiornamento:2025-06-29

Riferimento a questa documentazione al tuo assistente AI preferito

Pose una domanda e ottieni un riassunto del documento facendo riferimento a questa pagina e al provider AI di tua scelta

Il contenuto di questa pagina è stato tradotto con un'IA.

Vedi l'ultima versione del contenuto originale in inglese

Modifica questa documentazione

Se hai un’idea per migliorare questa documentazione, non esitare a contribuire inviando una pull request su GitHub.

Collegamento GitHub alla documentazione

Copia

Copia il Markdown del documento nella porta-documenti

react-Intl VS react-i18next VS intlayer | Internazionalizzazione (i18n) in React

Questa guida confronta tre opzioni consolidate per l'i18n in React: react-intl (FormatJS), react-i18next (i18next) e Intlayer. Ci concentriamo su applicazioni React plain (ad esempio, Vite, CRA, SPA). Se usi Next.js, consulta il nostro confronto dedicato a Next.js.

Valutiamo:

Architettura e organizzazione dei contenuti
TypeScript e sicurezza
Gestione delle traduzioni mancanti
Contenuti ricchi e capacità di formattazione
Prestazioni e comportamento di caricamento
Esperienza sviluppatore (DX), strumenti e manutenzione
SEO/routing (dipendente dal framework)

tl;dr: Tutti e tre possono localizzare un'app React. Se desideri contenuti a livello di componente, tipi TypeScript rigorosi, controlli delle chiavi mancanti in fase di build, dizionari ottimizzati con tree-shaking e strumenti editoriali integrati (Visual Editor/CMS + traduzione AI opzionale), Intlayer è la scelta più completa per codebase React modulari.

Posizionamento ad alto livello

react-intl - Formattazione basata su ICU e allineata agli standard (date/numeri/plurali) con un'API matura. I cataloghi sono tipicamente centralizzati; la sicurezza delle chiavi e la validazione in fase di build dipendono in gran parte da te.
react-i18next - Estremamente popolare e flessibile; namespaces, rilevatori e molti plugin (ICU, backend). Potente, ma la configurazione può espandersi man mano che i progetti crescono.
Intlayer - Modello di contenuto incentrato sul componente per React, tipizzazione TS rigorosa, controlli in fase di build, tree-shaking, oltre a Visual Editor/CMS e traduzioni assistite da AI. Funziona con React Router, Vite, CRA, ecc.

Matrice delle funzionalità (focus su React)

Mostra tutto il contenuto della tabella

Apri la tabella in una finestra modale per visualizzare tutti i dati in modo chiaro

Funzionalità	`react-intlayer` (Intlayer)	`react-i18next` (i18next)	`react-intl` (FormatJS)
Traduzioni Vicino ai Componenti	✅ Sì, contenuto collocato con ogni componente	❌ No	❌ No
Integrazione TypeScript	✅ Avanzata, tipi rigorosi generati automaticamente	⚠️ Base; configurazione extra per sicurezza	✅ Buona, ma meno rigorosa
Rilevamento Traduzioni Mancanti	✅ Evidenziazione errori TypeScript e errori/avvisi in fase di compilazione	⚠️ Principalmente stringhe di fallback a runtime	⚠️ Stringhe di fallback
Contenuto Ricco (JSX/Markdown/componenti)	✅ Supporto diretto	⚠️ Limitato / solo interpolazione	⚠️ Sintassi ICU, non vero JSX
Traduzione basata su AI	✅ Sì, supporta più provider AI. Utilizzabile con le proprie chiavi API. Considera il contesto della tua applicazione e l'ambito del contenuto	❌ No	❌ No
Editor Visivo	✅ Sì, Editor Visivo locale + CMS opzionale; può esternalizzare il contenuto del codice; integrabile	❌ No / disponibile tramite piattaforme di localizzazione esterne	❌ No / disponibile tramite piattaforme di localizzazione esterne
Routing Localizzato	✅ Sì, supporta percorsi localizzati out of the box (funziona con Next.js e Vite)	⚠️ Non integrato, richiede plugin (es. `next-i18next`) o configurazione personalizzata del router	❌ No, solo formattazione dei messaggi, il routing deve essere manuale
Generazione Dinamica delle Rotte	✅ Sì	⚠️ Plugin/ecosistema o configurazione manuale	❌ Non fornito
Pluralizzazione	✅ Modelli basati su enumerazioni	✅ Configurabile (plugin come i18next-icu)	✅ (ICU)
Formattazione (date, numeri, valute)	✅ Formatter ottimizzati (Intl sotto il cofano)	⚠️ Tramite plugin o utilizzo personalizzato di Intl	✅ Formatter ICU
Formato del contenuto	✅ .tsx, .ts, .js, .json, .md, .txt, (.yaml WIP)	⚠️ .json	✅ .json, .js
Supporto ICU	⚠️ In lavorazione	⚠️ Tramite plugin (i18next-icu)	✅ Sì
SEO Helpers (hreflang, sitemap)	✅ Strumenti integrati: helper per sitemap, robots.txt, metadata	⚠️ Plugin della community/manuale	❌ Non incluso nel core
Ecosistema / Community	⚠️ Più piccolo ma in rapida crescita e reattivo	✅ Il più grande e maturo	✅ Grande
Rendering lato server e Componenti Server	✅ Sì, ottimizzato per SSR / Componenti Server React	⚠️ Supportato a livello di pagina ma è necessario passare le funzioni t sull'albero dei componenti per i componenti server figli	❌ Non supportato, è necessario passare le funzioni t sull'albero dei componenti per i componenti server figli
Tree-shaking (caricamento solo del contenuto usato)	✅ Sì, per componente al momento della build tramite plugin Babel/SWC	⚠️ Di solito carica tutto (può essere migliorato con namespace/suddivisione del codice)	⚠️ Di solito carica tutto
Lazy loading	✅ Sì, per locale / per dizionario	✅ Sì (ad esempio, backend/namespace su richiesta)	✅ Sì (bundle di locale suddivisi)
Rimozione del contenuto non utilizzato	✅ Sì, per dizionario al momento della build	❌ No, solo tramite segmentazione manuale dei namespace	❌ No, tutti i messaggi dichiarati sono inclusi nel bundle
Gestione di Grandi Progetti	✅ Favorisce la modularità, adatto per sistemi di design	⚠️ Richiede una buona disciplina nella gestione dei file	⚠️ I cataloghi centrali possono diventare molto grandi

Confronto Approfondito

1) Architettura e scalabilità

react-intl / react-i18next: La maggior parte delle configurazioni mantiene cartelle di locale centralizzate per lingua, a volte suddivise in namespace (i18next). Funziona bene all'inizio ma diventa una superficie condivisa man mano che le app crescono.
Intlayer: Promuove dizionari per componente (o per funzionalità) collocati insieme all'interfaccia utente che servono. Questo mantiene chiara la proprietà, facilita la duplicazione/migrazione dei componenti e riduce il turnover delle chiavi tra i team. Il contenuto non utilizzato è più facile da identificare e rimuovere.

Perché è importante: Il contenuto modulare rispecchia l'interfaccia utente modulare. I grandi codebase React rimangono più puliti quando le traduzioni vivono con i componenti a cui appartengono.

2) TypeScript e sicurezza

react-intl: Tipizzazioni solide, ma nessuna tipizzazione automatica delle chiavi; devi applicare tu stesso i pattern di sicurezza.
react-i18next: Tipizzazioni forti per gli hook; la tipizzazione rigorosa delle chiavi richiede tipicamente configurazioni extra o generatori.
Intlayer: Genera automaticamente tipi rigorosi dal tuo contenuto. L'autocompletamento dell'IDE e gli errori a tempo di compilazione individuano errori di battitura e chiavi mancanti prima dell'esecuzione.

Perché è importante: Spostare i fallimenti a sinistra (alla fase di build/CI) riduce i problemi in produzione e accelera i cicli di feedback per gli sviluppatori.

3) Gestione delle traduzioni mancanti

react-intl / react-i18next: Di default usano fallback a runtime (eco della chiave o lingua predefinita). Puoi aggiungere linting/plugin, ma non è garantito durante la build.
Intlayer: Rilevamento a tempo di build con avvisi o errori quando mancano lingue/chiavi richieste.

Perché è importante: Il fallimento della CI su stringhe mancanti previene la “misteriosa” presenza di inglese nelle interfacce non inglesi.

4) Contenuti ricchi e formattazione

react-intl: Eccellente supporto ICU per plurali, selezioni, date/numeri e composizione dei messaggi. JSX può essere usato, ma il modello mentale rimane incentrato sul messaggio.
react-i18next: Interpolazione flessibile e <Trans> per incorporare elementi/componenti; ICU disponibile tramite plugin.
Intlayer: I file di contenuto possono includere nodi ricchi (JSX/Markdown/componenti) e metadati. La formattazione utilizza Intl sotto il cofano; i modelli di plurale sono ergonomici.

Perché è importante: I testi UI complessi (link, parti in grassetto, componenti inline) sono più facili da gestire quando la libreria supporta chiaramente i nodi React.

5) Prestazioni e comportamento di caricamento

react-intl / react-i18next: Di solito gestisci manualmente la divisione dei cataloghi e il caricamento lazy (namespace/import dinamici). Efficace ma richiede disciplina.
Intlayer: Esegue il tree-shaking dei dizionari non utilizzati e supporta il caricamento lazy per dizionario/per locale out-of-the-box.

Perché è importante: Bundle più piccoli e meno stringhe inutilizzate migliorano le prestazioni di avvio e navigazione.

6) DX, strumenti e manutenzione

react-intl / react-i18next: Ampio ecosistema comunitario; per i flussi editoriali solitamente si adottano piattaforme di localizzazione esterne.
Intlayer: Include un Editor Visivo gratuito e un CMS opzionale (mantieni i contenuti in Git o esternalizzali). Offre inoltre un’estensione per VSCode per la creazione di contenuti e una traduzione assistita da AI utilizzando le tue chiavi provider.

Perché è importante: Gli strumenti integrati accorciano il ciclo tra sviluppatori e autori di contenuti - meno codice di collegamento, meno dipendenze da fornitori.

Quando scegliere quale?

Scegli react-intl se desideri un formato messaggi ICU-first con un’API semplice e conforme agli standard e il tuo team è a suo agio nel mantenere manualmente cataloghi e controlli di sicurezza.
Scegli react-i18next se ti serve l’ampiezza dell’ecosistema di i18next (rilevatori, backend, plugin ICU, integrazioni) e accetti una configurazione più complessa per ottenere maggiore flessibilità.
Scegli Intlayer se apprezzi il contenuto a livello di componente, il TypeScript rigoroso, le garanzie a tempo di compilazione, il tree-shaking e gli strumenti editoriali completi - specialmente per applicazioni React grandi e modulari.

Note pratiche per la migrazione (react-intl / react-i18next → Intlayer)

Migra in modo incrementale: Inizia con una funzionalità o una rotta; mantieni i cataloghi legacy in parallelo durante la transizione.
Adotta dizionari per componente: Colloca il contenuto insieme ai componenti per ridurre l'accoppiamento.
Abilita controlli rigorosi: Lascia che gli errori a tempo di compilazione evidenzino precocemente chiavi/locale mancanti in CI.
Misura i bundle: Aspettati riduzioni man mano che le stringhe inutilizzate vengono eliminate.

Conclusione

Tutte e tre le librerie localizzano React in modo efficace. La differenza sta in quanta infrastruttura devi costruire per raggiungere una configurazione sicura e scalabile:

Con Intlayer, contenuti modulari, tipizzazione TypeScript rigorosa, sicurezza a tempo di compilazione, bundle ottimizzati con tree-shaking e strumenti editoriali sono impostazioni predefinite - non incombenze.
Se il tuo team valorizza la manutenibilità e la velocità in app React multi-locale e basate su componenti, Intlayer offre il flusso di lavoro per sviluppatori e contenuti più completo oggi disponibile.

next-i18next vs next-intl vs Intlayer