@intlayer/docs 9.5.6 → 9.5.7

package/blog/it/i18next_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next vs Intlayer: Benchmark e confronto 2026"
 description: "react-i18next e next-i18next misurati rispetto a Intlayer su Next.js e TanStack Start. Dimensioni del bundle, dispersione dei contenuti, reattività al cambio lingua ed esperienza di sviluppo."
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # i18next VS Intlayer | Benchmark di internazionalizzazione (i18n) per React e Next.js
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `i18next` è il framework di i18n più diffuso nell'ecosistema JavaScript. Attraverso `react-i18next` e `next-i18next`, alimenta un'ampia quota di applicazioni React e Next.js. Intlayer è un'alternativa basata su compilatore e con ambito per componente.
 
 Questo articolo li mette a confronto attraverso misurazioni concrete anziché elenchi di funzionalità. I dati provengono da [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), una suite open source che compila la stessa applicazione con ciascuna libreria e registra ciò che il browser scarica effettivamente.
@@ -99,6 +101,10 @@ Per ciascuna build, la suite registra:
 
 ### Risultati su Next.js (`next-i18next`)
 
+Seleziona le metriche e le librerie che ti interessano:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Libreria                          | Strategia      | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | Reattività E2E | Hydration |
 | --------------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | --------: |
 | **base** (senza i18n)             | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |   11.8 ms |
@@ -119,6 +125,15 @@ Per ciascuna build, la suite registra:
 - **Dimensioni dei componenti.** Un componente con `useTranslation()` compila tra i 26 e i 79 KB; lo stesso componente con `useIntlayer()` si attesta a 6.9 KB.
 - **L'idratazione** sale a 27.7 ms nella configurazione `dynamic`: l'istanza i18next si inizializza e risolve il proprio backend sul client prima che React possa idratare la pagina.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tabella completa, ogni libreria e ogni strategia, nel [rapporto di benchmark Next.js](https://intlayer.org/it/doc/benchmark/nextjs).
+
 ### Risultati su TanStack Start (`react-i18next`)
 
 Stessa applicazione di prova su TanStack Start con `react-i18next` puro, isolando la comparazione dalle specificità di Next.js.
@@ -141,8 +156,19 @@ Stessa applicazione di prova su TanStack Start con `react-i18next` puro, isoland
 - La riga `static` di Intlayer ha già **0% di dispersione di pagina** poiché vengono inclusi solo i dizionari importati dai componenti effettivi della pagina. Abilitando `importMode: 'dynamic'` si azzera anche la dispersione linguistica.
 - **Dimensioni componenti**: 24-27 KB con `react-i18next` contro 6-8 KB con Intlayer. `useTranslation()` vincola ogni componente all'istanza globale di i18next.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tabella completa nel [rapporto di benchmark TanStack Start](https://intlayer.org/it/doc/benchmark/tanstack).
+
 ## Origine del divario: Istanza globale vs dizionari compilati
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `i18next` è nato nel 2012 come runtime: un'istanza globale mantiene un archivio di risorse, i plugin la espandono e `t()` ricerca le chiavi a runtime. Tale architettura garantisce grande versatilità (qualsiasi framework, backend e formato), ma introduce inevitabilmente overhead:
 
 ```bash
@@ -166,7 +192,13 @@ Stessa applicazione di prova su TanStack Start con `react-i18next` puro, isoland
                 └── page.tsx     # deve sapere che necessita di ["common", "about"]
 ```
 
-L'istanza non può anticipare le chiavi richieste da un componente. Ottimizzare significa che **tu** devi suddividere i file in namespace, **tu** devi elencare i namespace richiesti da ogni pagina e **tu** devi mantenere allineata la lista quando i componenti vengono spostati. Come riportato nelle [note del benchmark](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "mantenere la sicurezza dei tipi e sapere esattamente quale namespace includere su quale pagina è un incubo".
+L'istanza non può anticipare le chiavi richieste da un componente. Ottimizzare significa che **tu** devi suddividere i file in namespace, **tu** devi elencare i namespace richiesti da ogni pagina e **tu** devi mantenere allineata la lista quando i componenti vengono spostati.
+
+La spesa cresce su due assi contemporaneamente, pagine e lingue:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
+Come riportato nelle [note del benchmark](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "mantenere la sicurezza dei tipi e sapere esattamente quale namespace includere su quale pagina è un incubo".
 
 Intlayer elimina l'istanza globale. I contenuti sono dichiarati accanto al componente e il compilatore risolve il grafico delle dipendenze durante il build:
 
@@ -193,7 +225,8 @@ Intlayer elimina l'istanza globale. I contenuti sono dichiarati accanto al compo
 
 ### Configurazione
 
-**next-i18next (App Router)**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```ts fileName="src/app/i18n/server.ts"
 import { createInstance } from "i18next";
@@ -228,7 +261,8 @@ export const initI18next = async (
 
 A questo si aggiunge un `I18nProvider` client che reinizializza l'istanza con le medesime opzioni, `generateStaticParams` e un elenco `namespaces` per ciascuna pagina.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -264,9 +298,13 @@ const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
 export default LocaleLayout;
 ```
 
+</Tab>
+</Tabs>
+
 ### Componente client
 
-**react-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="react-i18next" value="i18next">
 
 ```json fileName="src/locales/en/about.json"
 {
@@ -304,7 +342,8 @@ export const Counter = () => {
 
 > La pagina che renderizza questo componente deve caricare il namespace `about`, e `t("counter.label")` rimane una stringa semplice finché non si estende `CustomTypeOptions`.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -345,9 +384,13 @@ export const Counter = () => {
 
 `label` e `increment` sono tipizzati rigorosamente: ogni errore di battitura genera un errore TypeScript e una traduzione mancante blocca la compilazione.
 
+</Tab>
+</Tabs>
+
 ### Componente server sincrono
 
-**next-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -366,7 +409,8 @@ export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
 
 La pagina invoca `i18n.getFixedT(locale, "about")` e trasmette `t` e `locale` verso il basso tramite props.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -385,6 +429,9 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Conserva l'API di i18next, sfrutta le prestazioni di Intlayer
 
 Non serve riscrivere i componenti per beneficiare dei numeri del benchmark. `@intlayer/i18next`, `@intlayer/react-i18next` e `@intlayer/next-i18next` sono adattatori compatibili pronti all'uso: `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, plurali `_one` / `_other`, suffissi di contesto e `returnObjects` continuano a funzionare, erogati tramite i dizionari compilati da Intlayer.
@@ -415,18 +462,85 @@ Consulta le guide di migrazione: [i18next](https://intlayer.org/it/doc/migration
 
 ## Quando scegliere quale soluzione?
 
-- **Scegli i18next** se necessiti del suo ecosistema di plugin (rilevatori, backend, ICU, Locize), se gestisci la localizzazione anche fuori da React (servizi Node, vanilla JS, altri framework), se il tuo team ha già consolidata esperienza o se una piattaforma di traduzione richiede `locales/{lng}/{ns}.json`. Considera il tempo necessario per organizzare i namespace, configurare un backend e mantenere aggiornata la mappa delle route se le performance sono critiche.
-- **Scegli Intlayer** se desideri **contenuti integrati a livello di componente**, **TypeScript rigoroso**, **errori in fase di build per chiavi mancanti**, **tree-shaking e lazy loading a costo zero**, cambio lingua istantaneo, componenti server sincroni e strumenti editoriali integrati (editor visuale, CMS, traduzione con IA, server MCP). Ideale per codebase modulari e design system.
-- **Scegli gli adattatori `@intlayer/*-i18next`** se utilizzi già i18next e vuoi ottenere vantaggi immediati su bundle e reattività senza riscrivere i componenti.
+<AccordionGroup>
+<Accordion header="Scegliere i18next">
+
+Se necessiti del suo ecosistema di plugin (rilevatori, backend, ICU, Locize), se gestisci la localizzazione anche fuori da React (servizi Node, vanilla JS, altri framework), se il tuo team ha già consolidata esperienza o se una piattaforma di traduzione richiede `locales/{lng}/{ns}.json`. Considera il tempo necessario per organizzare i namespace, configurare un backend e mantenere aggiornata la mappa delle route se le performance sono critiche.
+
+</Accordion>
+<Accordion header="Scegliere Intlayer">
+
+Desideri **contenuti limitati ai componenti**, **TypeScript rigoroso**, **errori di chiavi mancanti in fase di compilazione**, **tree-shaking e lazy loading senza sforzo**, cambio istantaneo della lingua, componenti server sincroni e strumenti editoriali integrati ([Visual Editor](https://intlayer.org/it/doc/concept/editor), [CMS](https://intlayer.org/it/doc/concept/cms), [traduzione AI](https://intlayer.org/it/doc/concept/auto-fill), [server MCP](https://intlayer.org/it/doc/mcp-server)). Particolarmente rilevante per basi di codice modulari e sistemi di design.
+
+</Accordion>
+<Accordion header="Scegliere gli adattatori @intlayer/*-i18next">
+
+Utilizzi già i18next e desideri i vantaggi del bundle e della reattività senza riscrivere i componenti. I tuoi file `locales/{lng}/{ns}.json` rimangono l'unica fonte di verità. Misurato fianco a fianco in [i18next vs @intlayer/i18next](https://intlayer.org/it/blog/i18next-vs-intlayer-i18next).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Perché i18next è molto più pesante delle altre librerie?">
+
+È stato progettato come runtime agnostico rispetto al framework: un'istanza globale, una pipeline di plugin, un archivio di risorse, un risolutore di chiavi. Questa flessibilità viene compilata in ogni bundle. Un componente vuoto che importa solo la libreria costa **19.7 KB gzip** con `next-i18next` contro **5.5 KB** con `next-intlayer`, e questo costo viene pagato su ogni pagina, qualunque sia il peso dei tuoi contenuti.
+
+</Question>
+
+<Question title="Il caricamento lazy con un backend risolve il problema?">
+
+Risolve i byte, non la latenza. Il passaggio a `i18next-resources-to-backend` consente di risparmiare ~49 KB per pagina, ma aggiunge un round-trip di rete al cambio di lingua: **123 ms** nella configurazione `dynamic` e **185 ms** in `scoped-static`, contro **3-4 ms** con Intlayer. Anche l'idratazione sale a 27.7 ms perché l'istanza risolve il suo backend prima che React possa idratare.
+
+</Question>
+
+<Question title="Posso raggiungere lo 0% di leakage con i18next?">
+
+Sì, con `scoped-dynamic`: un namespace per route, un backend di risorse e una mappa pagina-namespace gestita a mano. Arriva a 163.4 KB per pagina su Next.js, comunque **+22 KB** rispetto ai 141.3 KB di Intlayer, che non ha richiesto alcuna configurazione. Consulta l'[ottimizzazione del bundle](https://intlayer.org/it/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Devo riscrivere i miei componenti per migrare?">
+
+No. `@intlayer/i18next`, `@intlayer/react-i18next` e `@intlayer/next-i18next` mantengono `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, plurali `_one` / `_other`, suffissi di contesto e `returnObjects`. Una sola riga di plugin in `next.config.ts` o `vite.config.ts`. Passo dopo passo nella [guida alla migrazione di next-i18next](https://intlayer.org/it/doc/migration/next-i18next).
+
+</Question>
+
+<Question title="Cosa succede ai miei plugin di i18next?">
+
+I backend e i rilevatori di lingua sono accettati ma inerti: non c'è più nulla da caricare o rilevare a runtime. Il rilevamento della lingua diventa la configurazione di routing di Intlayer (prefisso URL, cookie, header). Se la tua app recupera traduzioni da un CMS al momento della richiesta, usa invece il [CMS di Intlayer](https://intlayer.org/it/doc/concept/cms) o `intlayer pull` / `push`.
+
+</Question>
+
+</FAQ>
 
 ## Confronti correlati
 
-- [next-intl vs Intlayer](https://intlayer.org/it/blog/next-intl-vs-intlayer) (stesso benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/it/blog/lingui-vs-intlayer) (stesso benchmark)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/it/blog/vue-i18n-vs-intlayer-benchmark) (stesso benchmark)
+Stesso benchmark, altre librerie:
+
+- [next-intl vs Intlayer](https://intlayer.org/it/blog/next-intl-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/it/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/it/blog/vue-i18n-vs-intlayer-benchmark)
 - [next-i18next vs next-intl vs Intlayer](https://intlayer.org/it/blog/next-i18next-vs-next-intl-vs-intlayer)
 - [react-i18next vs react-intl vs Intlayer](https://intlayer.org/it/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Approfondire su i18next:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/it/blog/i18next-vs-intlayer-i18next), gli adattatori misurati sulla stessa applicazione
 - [i18next è superato?](https://intlayer.org/it/blog/is-i18next-outdated)
+- [Utilizzare Intlayer con i18next](https://intlayer.org/it/blog/intlayer-with-i18next) e [con react-i18next](https://intlayer.org/it/blog/intlayer-with-react-i18next)
+- [Come internazionalizzare un'app Next.js con next-i18next](https://intlayer.org/it/blog/nextjs-internationalization-using-next-i18next)
+
+Documenti di riferimento:
+
+- [Rapporto di benchmark Next.js](https://intlayer.org/it/doc/benchmark/nextjs) e [rapporto di benchmark TanStack Start](https://intlayer.org/it/doc/benchmark/tanstack)
+- Adattatori di compatibilità: [i18next](https://intlayer.org/it/doc/compatibility/i18next), [react-i18next](https://intlayer.org/it/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/it/doc/compatibility/next-i18next)
+- Guide alla migrazione: [i18next](https://intlayer.org/it/doc/migration/i18next), [react-i18next](https://intlayer.org/it/doc/migration/react-i18next), [next-i18next](https://intlayer.org/it/doc/migration/next-i18next)
+- [Ottimizzazione del bundle](https://intlayer.org/it/doc/concept/bundle-optimization) e [il compilatore Intlayer](https://intlayer.org/it/doc/compiler)
+- [i18n per componente vs centralizzata](https://intlayer.org/it/blog/per-component-vs-centralized-i18n)
+- [i18n guidata da compilatore vs dichiarativa](https://intlayer.org/it/blog/compiler-vs-declarative-i18n)
 
 ## Stelle su GitHub
 

package/blog/it/lingui_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "Lingui vs Intlayer: Benchmark & Confronto 2026"
 description: "Due librerie di i18n basate su compilatore misurate su Next.js e TanStack Start. Dimensioni del bundle, leakage dei contenuti, dimensioni dei componenti, idratazione, reattività al cambio lingua ed esperienza sviluppatore."
 keywords:
@@ -24,6 +24,8 @@ author: aymericzip
 
 # Lingui VS Intlayer | Benchmark di Internazionalizzazione (i18n) per React & Next.js
 
+![JavaScript i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
 Lingui e Intlayer sono le uniche due librerie in questo benchmark che si affidano a un **compilatore** piuttosto che a un semplice runtime. Lingui estrae i messaggi dalle macro in fase di compilazione e compila cataloghi per lingua. Intlayer compila dizionari per componente e applica il tree-shaking per lingua. Sulla carta dovrebbero essere molto simili. I numeri mostrano dove divergono.
 
 I dati provengono da [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), una suite open source che compila la medesima applicazione con ciascuna libreria e registra ciò che il browser scarica ed esegue realmente.
@@ -96,6 +98,10 @@ Per ogni build vengono registrati i seguenti parametri:
 
 ### Risultati su Next.js
 
+Seleziona le metriche e le librerie che ti interessano:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Libreria            | Strategia      | Lib size (gz) | Page JS media (gz) | Leak lingua | Leak pagina | Componente medio (gz) | Reattività E2E | Idratazione |
 | ------------------- | -------------- | ------------: | -----------------: | ----------: | ----------: | --------------------: | -------------: | ----------: |
 | **base** (no i18n)  | -              |        0,0 KB |           141,0 KB |        0,0% |        0,0% |                0,9 KB |        13,4 ms |     11,8 ms |
@@ -114,6 +120,15 @@ Per ogni build vengono registrati i seguenti parametri:
 - **Il fallback della lingua sorgente si disperde.** Perfino nelle configurazioni più ottimizzate, **tra il 3% e il 15% delle stringhe inglesi viaggia nelle pagine francesi**. Le macro Lingui mantengono il testo sorgente nel bundle come fallback. Intlayer risolve i fallback in fase di compilazione e invia solo la lingua attiva.
 - **Le dimensioni dei componenti aumentano drasticamente in `scoped-dynamic`.** Ciascun componente compilato isolatamente pesa in media **152,6 KB**, poiché tutti i cataloghi delle rotte risultano raggiungibili attraverso gli import. Lo stesso componente con `useIntlayer()` pesa in media **6,9 KB**.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tabella completa, ogni libreria e ogni strategia, nel [report di benchmark Next.js](https://intlayer.org/it/doc/benchmark/nextjs).
+
 ### Risultati su TanStack Start
 
 | Libreria                    | Strategia      | Lib size (gz) | Page JS media (gz) | Leak lingua | Leak pagina | Componente medio (gz) | Reattività E2E | Idratazione |
@@ -135,8 +150,19 @@ Per ogni build vengono registrati i seguenti parametri:
 - **La riga `static` di Intlayer raggiunge già lo 0% di leakage di pagina** perché include esclusivamente i dizionari utilizzati dai componenti di quella pagina. Una sola riga (`importMode: 'dynamic'`) azzera anche il leakage di lingua.
 - **`@intlayer/lingui`** mantiene la sintassi delle macro di Lingui servendosi dei dizionari di Intlayer. Cede qualche kilobyte per pagina (137 KB, restando attivo il runtime delle macro) in cambio di componenti molto più snelli (12,8 KB) e un'idratazione più reattiva. Rappresenta una soluzione transitoria ideale.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tabella completa nel [report di benchmark TanStack Start](https://intlayer.org/it/doc/benchmark/tanstack).
+
 ## Perché questa differenza? Due compilatori, due unità di lavoro
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Entrambi gli strumenti utilizzano un compilatore, ma compilano elementi strutturalmente differenti.
 
 **Lingui compila cataloghi.** Le macro nel codice sorgente vengono estratte in un file `.po` per lingua e quindi compilate in un modulo JS per lingua. L'unità operativa è la **lingua**. Dividere a livello più granulare, per rotta o per componente, comporta la creazione di cataloghi multipli, una configurazione articolata di `lingui.config.ts` e la gestione manuale dei caricamenti. L'istanza `I18n` è globale; ogni `useLingui()` vi iscrive il componente.
@@ -176,7 +202,9 @@ Entrambi gli strumenti utilizzano un compilatore, ma compilano elementi struttur
             └── about.content.ts
 ```
 
-Ecco perché l'architettura `scoped-dynamic` è un risultato nativo e automatico con Intlayer, mentre rappresenta un progetto di configurazione complesso con Lingui.
+Ecco perché l'architettura `scoped-dynamic` è un risultato nativo e automatico con Intlayer, mentre rappresenta un progetto di configurazione complesso con Lingui. Il divario si allarga su due assi contemporaneamente, pagine e lingue:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
 
 > Per replicare le prestazioni della riga `dynamic`, imposta `dictionary.importMode: 'dynamic'` nel file `intlayer.config.ts`. Consulta la [guida all'ottimizzazione del bundle](https://intlayer.org/it/doc/concept/bundle-optimization).
 
@@ -184,7 +212,8 @@ Ecco perché l'architettura `scoped-dynamic` è un risultato nativo e automatico
 
 ### Configurazione
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```ts fileName="lingui.config.ts"
 import { defineConfig } from "@lingui/cli";
@@ -215,7 +244,8 @@ export const loadCatalog = async (locale: string) => {
 
 Successivamente occorre aggiungere `@lingui/babel-plugin-lingui-macro` (o `@lingui/swc-plugin`) al bundler, eseguire `lingui extract` dopo ogni modifica ai testi, `lingui compile` prima della compilazione generale, e avvolgere la radice con `<I18nProvider i18n={i18n}>`.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -232,9 +262,12 @@ export default config;
 
 Aggiungi `intlayer()` a `vite.config.ts` (o `withIntlayer()` a `next.config.ts`) e avvolgi l'albero con `<IntlayerProvider>`. Nessun passaggio manuale di estrazione o compilazione: i dizionari vengono processati direttamente all'avvio del bundler.
 
+</Tab>
+</Tabs>
 ### Creazione del componente
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```tsx fileName="src/components/Counter.tsx"
 import { useState } from "react";
@@ -258,7 +291,8 @@ export const Counter = () => {
 
 Il testo in inglese risiede nel componente; la traduzione in francese si trova in `src/locales/fr/messages.po` sotto un ID con hash, generato dopo aver eseguito `lingui extract`. Dimenticare l'estrazione o la compilazione comporterà l'uso silenzioso dell'inglese.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -297,11 +331,14 @@ export const Counter = () => {
 
 Entrambe le lingue risiedono nello stesso file accanto al componente. Un valore mancante per `fr` blocca il build, mentre una chiave inesistente scatena immediatamente un errore TypeScript.
 
+</Tab>
+</Tabs>
 ### Fuori dai componenti
 
 Metadati, loader, funzioni server: ovunque non sia presente un albero React.
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```ts fileName="src/routes/$locale/about.tsx"
 import { setupI18n } from "@lingui/core";
@@ -324,7 +361,8 @@ export const loader = async ({ params }: { params: { locale: string } }) => {
 
 Occorre una nuova istanza `I18n` per chiamata, l'importazione esplicita del catalogo corrispondente e l'uso di `msg` + `i18n._()` al posto di `t`. Come rilevato nelle [note del benchmark](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md), intuire quando utilizzare `t`, `` t` ` ``, `i18n.t()`, `msg` o `<Trans>` risulta spesso poco intuitivo.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/routes/$locale/about.tsx"
 import { getIntlayer } from "intlayer";
@@ -336,6 +374,9 @@ export const loader = async ({ params }: { params: { locale: string } }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Mantenere le macro di Lingui con i dizionari di Intlayer
 
 `@intlayer/lingui` è un adattatore compatibile per `@lingui/core` e `@lingui/react`. Le macro continuano a compilarsi come di consueto; le chiamate a `i18n._()` generate vengono soddisfatte dai dizionari di Intlayer, mentre i plugin di sincronizzazione `.po` preservano i cataloghi esistenti come fonte di verità. Plurali e selezioni ICU vengono riprodotti in modo identico.
@@ -353,16 +394,82 @@ Mantieni `@lingui/babel-plugin-lingui-macro` / `@lingui/swc-plugin` nella build,
 
 ## Quale soluzione scegliere?
 
-- **Scegli Lingui** se hai bisogno di **ICU MessageFormat** con macro tipizzate, se i tuoi traduttori operano su file **`.po`** con piattaforme TMS preesistenti, se preferisci dichiarare i testi sorgente direttamente nel JSX e se il team gestisce agilmente il ciclo di estrazione, compilazione e partizionamento dei cataloghi. Il JavaScript per pagina è estremamente competitivo una volta configurato il lazy loading.
-- **Scegli Intlayer** se desideri **contenuti modulari per componente**, **TypeScript rigoroso**, **errori a tempo di compilazione per chiavi mancanti**, **tree-shaking e caricamento lazy automatici a configurazione zero**, componenti compatti, idratazione veloce, cambio lingua istantaneo e una suite editoriale nativa (Visual Editor, CMS, traduzione IA, server MCP). Particolarmente indicato per basi di codice modulari e design system.
-- **Scegli `@intlayer/lingui`** se utilizzi già Lingui e desideri passare all'architettura a dizionari di Intlayer in modo graduale senza riscrivere le macro.
+<AccordionGroup>
+<Accordion header="Scegli Lingui">
+
+Vuoi **ICU MessageFormat** con macro tipizzate, i tuoi traduttori lavorano in **`.po`** con una pipeline TMS esistente, preferisci stringhe sorgente in linea in JSX e il tuo team gestisce comodamente il flusso di estrazione / compilazione / suddivisione dei cataloghi. Il suo JS per pagina è competitivo una volta configurato il caricamento lazy.
+
+</Accordion>
+<Accordion header="Scegli Intlayer">
+
+Vuoi **contenuto con ambito per componente**, **TypeScript rigoroso**, **errori di chiavi mancanti in fase di compilazione**, **tree-shaking e caricamento lazy senza sforzo**, componenti leggeri, idratazione rapida, cambio istantaneo di lingua e strumenti editoriali integrati ([Editor Visuale](https://intlayer.org/it/doc/concept/editor), [CMS](https://intlayer.org/it/doc/concept/cms), [traduzione AI](https://intlayer.org/it/doc/concept/auto-fill), [server MCP](https://intlayer.org/it/doc/mcp-server)). Particolarmente rilevante per grandi codebase modulari e design system.
+
+</Accordion>
+<Accordion header="Scegli @intlayer/lingui">
+
+Usi già Lingui e desideri passare ai dizionari Intlayer gradualmente senza toccare le macro. I tuoi cataloghi `.po` rimangono la fonte di verità tramite il [plugin di sincronizzazione PO](https://intlayer.org/it/doc/compatibility/lingui). Misurato fianco a fianco in [Lingui vs @intlayer/lingui](https://intlayer.org/it/blog/lingui-vs-intlayer-lingui).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Anche Lingui compila. Perché l'output è così diverso?">
+
+Perché l'unità di compilazione differisce. Lingui compila **un catalogo per lingua**: tutto il resto (cataloghi per route, lazy loading, esclusione del fallback dal bundle) richiede configurazione. Intlayer compila **un dizionario per componente**, quindi l'ambito delle route deriva direttamente dalla compilazione. Ecco perché un componente Lingui compilato isolatamente pesa 58-153 KB contro i 6-8 KB di Intlayer.
+
+</Question>
+
+<Question title="Perché la dispersione di lingua non raggiunge mai lo 0% con Lingui?">
+
+Le macro mantengono il messaggio sorgente disponibile come fallback a runtime, quindi la stringa inglese viene inviata insieme alla sua traduzione. Il benchmark misura il **3-15% di stringhe `en` nelle pagine `fr`** in ogni configurazione ottimizzata. Intlayer risolve i fallback in fase di compilazione e invia solo la lingua attiva.
+
+</Question>
+
+<Question title="Il JavaScript per pagina di Lingui è davvero competitivo?">
+
+Sì, e su TanStack Start vince di un soffio: 115.2 KB in `dynamic` contro 118.6 KB per Intlayer. I cataloghi compilati con ID con hash sono compatti. Il costo si manifesta altrove: idratazione a 28-34 ms contro 11-14 ms, e un cambio di lingua a **42 ms** nella configurazione `scoped-dynamic`.
+
+</Question>
+
+<Question title="Devo rinunciare alle macro per migrare?">
+
+No. `@intlayer/lingui` mantiene la compilazione di `` t`...` ``, `<Trans>`, `msg`, `plural`, `select` e `selectOrdinal` come prima; cambia solo ciò rispetto a cui `i18n._()` risolve. Mantieni `@lingui/babel-plugin-lingui-macro` o `@lingui/swc-plugin` nella compilazione. Vedi la [documentazione sulla compatibilità di Lingui](https://intlayer.org/it/doc/compatibility/lingui).
+
+</Question>
+
+<Question title="Che ne è dei passaggi di estrazione e compilazione?">
+
+Rimangono per le macro e scompaiono per i contenuti nativi di Intlayer. I dizionari `.content.ts` vengono creati all'esecuzione del bundler, senza un passaggio CLI separato, e [`intlayer test`](https://intlayer.org/it/doc/concept/cli) blocca la CI in caso di chiave mancante anziché ricadere silenziosamente sulla stringa sorgente.
+
+</Question>
+
+</FAQ>
 
 ## Confronti correlati
 
-- [next-intl vs Intlayer](https://intlayer.org/it/blog/next-intl-vs-intlayer) (sullo stesso benchmark)
-- [i18next vs Intlayer](https://intlayer.org/it/blog/i18next-vs-intlayer) (sullo stesso benchmark)
-- [vue-i18n vs Intlayer](https://intlayer.org/it/blog/vue-i18n-vs-intlayer-benchmark) (sullo stesso benchmark)
-- [Compilatore vs i18n dichiarativo](https://intlayer.org/it/blog/compiler-vs-declarative-i18n)
+Stesso benchmark, altre librerie:
+
+- [next-intl vs Intlayer](https://intlayer.org/it/blog/next-intl-vs-intlayer)
+- [i18next vs Intlayer](https://intlayer.org/it/blog/i18next-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/it/blog/vue-i18n-vs-intlayer-benchmark)
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/it/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [react-i18next vs react-intl vs Intlayer](https://intlayer.org/it/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Approfondimenti:
+
+- [Lingui vs @intlayer/lingui](https://intlayer.org/it/blog/lingui-vs-intlayer-lingui), l'adattatore misurato sulla stessa applicazione
+- [Compiler-driven vs declarative i18n](https://intlayer.org/it/blog/compiler-vs-declarative-i18n)
+- [Per-component vs centralized i18n](https://intlayer.org/it/blog/per-component-vs-centralized-i18n)
+- [ICU message format explained](https://intlayer.org/it/blog/icu-message-format)
+
+Documenti di riferimento:
+
+- [Report di benchmark Next.js](https://intlayer.org/it/doc/benchmark/nextjs) e [report di benchmark TanStack Start](https://intlayer.org/it/doc/benchmark/tanstack)
+- [Compat adapter: Lingui](https://intlayer.org/it/doc/compatibility/lingui)
+- [Ottimizzazione del bundle](https://intlayer.org/it/doc/concept/bundle-optimization) e [il compilatore Intlayer](https://intlayer.org/it/doc/compiler)
 
 ## Stelle su GitHub