@intlayer/docs 9.5.6 → 9.5.8

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
 

package/blog/it/next-intl_vs_intlayer-next-intl.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs @intlayer/next-intl: Stessa API, Bundle Diverso"
 description: Cosa cambia quando le importazioni di next-intl di un'app Next.js vengono servite dall'adapter di compatibilità @intlayer/next-intl. Dimensione del bundle, perdite, dimensione dei componenti e idratazione misurate sullo stesso codice, più cosa mantiene, ignora e non può sostituire l'adapter.
 keywords:
@@ -26,6 +26,8 @@ author: aymericzip
 
 # next-intl VS @intlayer/next-intl | Stessa API, Bundle Diverso
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `@intlayer/next-intl` è un compat adapter: espone l'API di `next-intl` (`useTranslations`, `getTranslations`, `useLocale`, `t.rich()`, ICU plurals, `NextIntlClientProvider`...) e la serve da dizionari compilati da Intlayer. Il codice dell'applicazione non cambia. Il bundle sì.
 
 Questo articolo confronta i due sulla stessa applicazione Next.js, costruita una volta con `next-intl` e una volta con l'adapter. I numeri provengono da [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), una suite open-source che registra ciò che il browser effettivamente scarica. Se vuoi il confronto `next-intl` vs Intlayer come librerie, leggi [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer). Questo riguarda ciò che l'adapter cambia quando mantieni i tuoi componenti come sono.
@@ -109,6 +111,10 @@ Per ogni build, la suite registra:
 
 ### Risultati su Next.js
 
+Seleziona le metriche e le librerie che ti interessano:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Setup                     | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity |   Hydration |
 | ------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | ----------: |
 | **base** (no i18n)        | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |     11.8 ms |
@@ -129,6 +135,15 @@ Per ogni build, la suite registra:
 - **L'idratazione è 2 ms più veloce** (12.8 vs 14.7 ms): non c'è nessun oggetto messaggio da deserializzare dal payload RSC prima che React possa idrare.
 - **L'adapter non è il runtime nativo.** `next-intlayer` si posiziona a **141.3 KB**, +0.3 KB sopra l'app base, con un runtime di 5.5 KB. L'adapter trasporta la superficie API di `next-intl` (`useFormatter`, `t.rich`, il risolutore ICU) in cima al core di Intlayer, da cui 8.0 KB e +6 KB per pagina. È il ponte, non la destinazione.
 
+<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 (`use-intl`)
 
 `use-intl` è il core framework-agnostico di `next-intl`. Il suo adapter, `@intlayer/use-intl`, segue lo stesso design con un plugin Vite (`@intlayer/use-intl/plugin`).
@@ -152,11 +167,24 @@ Per ogni build, la suite registra:
 - **Lo switching delle locale è più veloce.** Gli setup `use-intl` ottimizzati impiegano **13-21 ms** per aggiornare `html[lang]`; l'adapter impiega **4-9 ms**. Meno componenti vengono renderizzati di nuovo, e niente viene ripreso da un albero di messaggi.
 - **`static` mantiene ogni locale.** La riga `static` dell'adapter mostra una perdita di locale del 49,7%, la stessa di Intlayer nativo in modalità `static`: tutte le locale vengono raggruppate, solo i dizionari della pagina. Una riga di configurazione (`importMode: 'dynamic'`) la rimuove.
 
+<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é i numeri cambiano
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Poiché niente nel componente è cambiato, i guadagni provengono interamente da ciò a cui `useTranslations` è associato.
 
-**Con `next-intl`**, il binding è il provider. `NextIntlClientProvider` riceve l'intero oggetto `messages` per la locale; ogni `useTranslations("about")` legge da esso. Il bundler vede un componente che importa un hook che legge un context, e non può sapere che solo il ramo `about` è utilizzato. Le route di seguito condividono tutti lo stesso oggetto message, quindi la colonna page-leak legge ~90% fino a quando non dividi il file tu stesso.
+**Con `next-intl`**, il binding è il provider. `NextIntlClientProvider` riceve l'intero oggetto `messages` per la locale; ogni `useTranslations("about")` legge da esso. Il bundler vede un componente che importa un hook che legge un context, e non può sapere che solo il ramo `about` è utilizzato. Le route di seguito condividono tutti lo stesso oggetto message, quindi la colonna page-leak legge ~90% fino a quando non dividi il file tu stesso, e lo spreco cresce su due assi contemporaneamente, pagine e impostazioni locali:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
 
 ```bash
 .
@@ -280,25 +308,106 @@ export default withIntlayer(nextConfig);
 
 ## Limiti da conoscere prima di iniziare
 
-- **La configurazione del routing si sposta in `intlayer.config.ts`.** `createNavigation(routing)` e `createMiddleware(routing)` mantengono la loro firma ma ignorano l'argomento: le locale, la locale predefinita e la strategia di prefisso provengono dalla configurazione `routing` di Intlayer. Se utilizzi i `pathnames` localizzati di `next-intl` (`/about` → `/a-propos`), l'adapter non li interpola; `routing.rewrite` di Intlayer copre quel caso ma è una modifica separata.
-- **`useTranslations()` senza namespace non è vincolato.** Il pass di ottimizzazione ha bisogno di uno spazio dei nomi statico per sapere quale dizionario importare. Una chiamata nuda funziona ancora, attraverso un registro di runtime che fa riferimento a ogni dizionario, che è esattamente la perdita che stavi cercando di rimuovere. Passa il namespace.
-- **L'adapter non è gratuito.** 8.0 KB di runtime rispetto a 5.5 KB per `next-intlayer`, e +6-7 KB per pagina rispetto alla build nativa. Questo copre la superficie API di `next-intl`. Se raggiungi il punto in cui ogni componente è stato spostato a `useIntlayer`, elimina l'adapter.
-- **`messages`, `timeZone`, `now` sul provider vengono ignorati.** I formatter sono supportati da `Intl` nativo e solo la locale ne influenza l'output; se dipendi da un fuso orario forzato o da un `now` fisso per date stabili durante l'hydration, gestiscilo nel sito di chiamata.
+<AccordionGroup>
+<Accordion header="La configurazione di routing si sposta in intlayer.config.ts">
+
+`createNavigation(routing)` e `createMiddleware(routing)` mantengono la loro firma ma ignorano l'argomento: lingue, lingua predefinita e strategia di prefisso provengono dalla configurazione `routing` di Intlayer. Se usi i `pathnames` localizzati di `next-intl` (`/about` in `/a-propos`), l'adattatore non li interpola; `routing.rewrite` di Intlayer copre quel caso ma è una modifica separata.
+
+</Accordion>
+<Accordion header="useTranslations() senza namespace non è associato">
+
+Il passaggio di ottimizzazione ha bisogno di un namespace statico per sapere quale dizionario importare. Una chiamata senza namespace funziona comunque, tramite un registro di runtime che fa riferimento a ciascun dizionario, il che corrisponde esattamente alla dispersione che stavi cercando di rimuovere. Passa il namespace.
+
+</Accordion>
+<Accordion header="L'adattatore non è gratuito">
+
+8.0 KB di runtime contro 5.5 KB per `next-intlayer` e +6-7 KB per pagina rispetto alla build nativa. Paga per la superficie API di `next-intl`. Se arrivi al punto in cui ogni componente è passato a `useIntlayer`, rimuovi l'adattatore.
+
+</Accordion>
+<Accordion header="messages, timeZone e now sul provider vengono ignorati">
+
+I formattatori sono supportati dall'API nativa `Intl` e solo la lingua influenza il loro output. Se ti affidi a un fuso orario forzato o a un `now` fisso per date stabili all'idratazione, gestiscilo nel punto di chiamata. Vedi [formattazione di date, orari e numeri](https://intlayer.org/it/blog/date-time-number-formatting-locales).
+
+</Accordion>
+</AccordionGroup>
 
 ## Quando usare quale?
 
-- **Rimani su `next-intl`** se la tua app è piccola, il tuo bundle non è una preoccupazione, e il tuo team è a suo agio nel gestire i namespace e `pick()` per pagina.
-- **Usa `@intlayer/next-intl`** se sei attualmente su `next-intl` e desideri i vantaggi di bundle, leakage e hydration, chiavi tipizzate e gli strumenti CLI / CMS senza una riscrittura. Questo è il punto di ingresso consigliato per qualsiasi codebase `next-intl` esistente.
-- **Vai nativo (`next-intlayer`)** per i nuovi progetti, o una volta che l'adapter ha svolto il suo lavoro. È il più leggero dei tre (5.5 KB, +0.3 KB per pagina) e sblocca i server component sincroni, i file `.content.ts` per componente e l'intero set di funzionalità.
+<AccordionGroup>
+<Accordion header="Rimani su next-intl">
+
+La tua app è piccola, il bundle non è un problema e il tuo team gestisce comodamente namespace e `pick()` per pagina.
+
+</Accordion>
+<Accordion header="Usa @intlayer/next-intl">
+
+Usi già `next-intl` oggi e desideri i vantaggi di bundle, dispersione e idratazione, chiavi tipizzate e strumenti CLI / CMS senza dover riscrivere il codice. Questo è il punto di partenza consigliato per qualsiasi codebase `next-intl` esistente.
+
+</Accordion>
+<Accordion header="Passa al nativo (next-intlayer)">
+
+Per nuovi progetti, o una volta che l'adattatore ha fatto il suo lavoro. È il più leggero dei tre (5.5 KB, +0.3 KB per pagina) e sblocca componenti server sincroni, file `.content.ts` per componente e l'intero set di funzionalità. Inizia con [Intlayer con Next.js](https://intlayer.org/it/doc/environment/nextjs).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Il codice della mia applicazione rimane davvero intatto?">
+
+Su Next.js, sì per i componenti: la build di benchmark ha modificato solo `next.config.ts` e `intlayer.config.ts`. `getRequestConfig` in `src/i18n.ts`, la prop `messages` sul provider e le chiamate `pick()` per pagina diventano codice morto che puoi eliminare in seguito.
+
+</Question>
+
+<Question title="Cosa succede ai messaggi ICU?">
+
+Continuano a funzionare. `t("key", { count })`, `t.rich()`, `t.markup()`, `select`, `selectordinal`, `#` e `{ts, date, long}` vengono risolti dal risolutore ICU di Intlayer. Vedi [formato di messaggio ICU](https://intlayer.org/it/blog/icu-message-format).
+
+</Question>
+
+<Question title="Perché l'adattatore è più pesante di next-intlayer nativo?">
+
+Porta con sé la superficie API di `next-intl` sopra il core di Intlayer: `useFormatter`, `t.rich`, il risolutore ICU, gli helper di navigazione. Si tratta di 8.0 KB contro 5.5 KB, e +6 KB per pagina. È il ponte, non la destinazione finale.
+
+</Question>
+
+<Question title="Posso migrare componente per componente?">
+
+Sì. Qualsiasi componente può passare da `useTranslations("about")` a `useIntlayer("about")` con un file `.content.ts` co-locato. I dizionari JSON e `.content.ts` coesistono e si uniscono.
+
+</Question>
+
+<Question title="I percorsi localizzati (pathnames) funzionano?">
+
+Non tramite i `pathnames` di `next-intl`: l'adattatore li accetta per la tipizzazione ma non li interpola. Usa invece `routing.rewrite` di Intlayer, che emette i letterali localizzati nel registro dei tipi.
+
+</Question>
+
+</FAQ>
 
 ## Confronti correlati
 
-- [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer) (le librerie, lo stesso benchmark)
-- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (stessa serie di adapter)
-- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (stessa serie di adapter)
-- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/blog/vue-i18n-vs-intlayer-vue-i18n) (stessa serie di adapter)
-- [Guida alla migrazione: next-intl to Intlayer](https://intlayer.org/doc/migration/next-intl)
-- [Riferimento adapter di compatibilità: next-intl](https://intlayer.org/doc/compatibility/next-intl)
+Stessa serie di adattatori:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/it/blog/i18next-vs-intlayer-i18next)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/it/blog/lingui-vs-intlayer-lingui)
+- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/it/blog/vue-i18n-vs-intlayer-vue-i18n)
+
+Le librerie a confronto diretto:
+
+- [next-intl vs Intlayer](https://intlayer.org/it/blog/next-intl-vs-intlayer), stesso benchmark
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/it/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [Is next-intl outdated?](https://intlayer.org/it/blog/is-next-intl-outdated)
+
+Documenti di riferimento:
+
+- [Compat adapter: next-intl](https://intlayer.org/it/doc/compatibility/next-intl)
+- [Guida alla migrazione: da next-intl a Intlayer](https://intlayer.org/it/doc/migration/next-intl)
+- [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)
+- [Ottimizzazione del bundle](https://intlayer.org/it/doc/concept/bundle-optimization) e [il compilatore Intlayer](https://intlayer.org/it/doc/compiler)
+- [Editor Visuale](https://intlayer.org/it/doc/concept/editor), [CMS](https://intlayer.org/it/doc/concept/cms) e [traduzione AI](https://intlayer.org/it/doc/concept/auto-fill)
 
 ## Conclusione