@intlayer/docs 9.5.6 → 9.5.8

package/blog/it/next-intl_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs Intlayer: Benchmark & Comparison 2026"
 description: Dimensione del bundle, perdita di contenuti, reattività del cambio locale e esperienza dello sviluppatore misurate su Next.js e TanStack Start. Quale libreria i18n dovresti scegliere nel 2026?
 keywords:
@@ -24,6 +24,8 @@ author: aymericzip
 
 # next-intl VS Intlayer | Benchmark di Internazionalizzazione (i18n) per Next.js
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `next-intl` è la libreria i18n più popolare per Next.js. Intlayer è un'alternativa basata su compiler e component-scoped. Entrambi localizzano un'applicazione App Router. La domanda è quanto costi ciascuno una volta che l'app è compilata.
 
 Questo articolo non è un tutorial. È un confronto supportato da numeri da [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), una suite di benchmark open-source che compila la stessa applicazione con ciascuna libreria e misura ciò che il browser scarica effettivamente ed esegue.
@@ -96,6 +98,10 @@ Per ogni build, la suite registra:
 
 ### Risultati su Next.js (App Router)
 
+Seleziona le metriche e le librerie che ti interessano:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Library                        | 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 |
@@ -116,6 +122,15 @@ Per ogni build, la suite registra:
 - **Dimensione del componente.** Un componente che chiama `useTranslations()` compila in media a 21.8 KB; lo stesso componente con `useIntlayer()` compila a 6.9 KB. Nella configurazione `scoped-static` i componenti `next-intl` aumentano a 80.1 KB perché ognuno inserisce il suo catalogo di namespace.
 - **Reattività e idratazione** sono sullo stesso livello per entrambe le librerie su Next.js (15-18 ms). Nessuna è un collo di bottiglia qui.
 
+<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 indipendente dal framework di `next-intl`. Stessa API, stesso formato di messaggio. Confrontarlo con `intlayer` su TanStack Start rimuove le parti specifiche di Next.js dall'equazione.
@@ -139,8 +154,19 @@ Per ogni build, la suite registra:
 - **La dimensione del componente è dove l'architettura si mostra**: 76-87 KB per componente con `use-intl` versus 6-8 KB con Intlayer. `useTranslations()` lega ogni componente all'albero dei messaggi globale; `useIntlayer()` lo lega al suo dizionario personale.
 - **Cambio di locale** è 2-4 volte più veloce con Intlayer (3 ms vs 7-21 ms).
 
+<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é il divario? Cataloghi centralizzati 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)
+
 `next-intl` segue il modello classico: un JSON per locale, caricato in `getRequestConfig`, inserito in un `NextIntlClientProvider`, letto attraverso `t("namespace.key")`.
 
 ```bash
@@ -162,6 +188,10 @@ Per ogni build, la suite registra:
 
 Il runtime non può sapere quali chiavi una pagina utilizzerà, quindi il valore predefinito sicuro è inviare l'intero catalogo. Ottimizzare significa **tu** dividi il catalogo in namespace, **tu** decidi quali namespace ogni pagina ha bisogno, e **tu** mantieni quel mapping sincronizzato mentre i componenti si muovono. La riga `scoped-dynamic` del benchmark è la ricompensa per quel lavoro, e la maggior parte dei team non ci arriva mai.
 
+Il costo di non arrivarci 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)
+
 Intlayer capovolge la responsabilità. Il contenuto è dichiarato accanto al componente:
 
 ```bash
@@ -189,7 +219,8 @@ Al momento della compilazione il compiler (`@intlayer/swc` / `@intlayer/babel`)
 
 ### Componente Client
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```json fileName="messages/en.json"
 {
@@ -224,7 +255,8 @@ export const Counter = () => {
 
 > Ricorda di includere il namespace `counter` nei messaggi passati a `NextIntlClientProvider` su ogni pagina che renderizza questo componente.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -265,11 +297,14 @@ export const Counter = () => {
 
 Niente da registrare sulla pagina: il componente porta con sé il suo contenuto.
 
+</Tab>
+</Tabs>
 ### Componente server sincrono
 
 I componenti design-system (navbar, footer, cards) sono spesso componenti server renderizzati come figli di componenti client, quindi non possono essere `async`.
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -287,7 +322,8 @@ export const ServerCounter = ({ t, formattedCount }: ServerCounterProps) => (
 
 La pagina deve `await getTranslations("counter")` e `await getFormatter()`, quindi passare i risultati come props. Il componente non è più autonomo.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -308,9 +344,12 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
 ### Metadati
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import type { Metadata } from "next";
@@ -344,7 +383,8 @@ export const generateMetadata = async ({
 };
 ```
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import { getIntlayer, getMultilingualUrls } from "intlayer";
@@ -368,6 +408,9 @@ export const generateMetadata = async ({
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Mantieni l'API di next-intl, ottieni l'output di Intlayer
 
 Non devi riscrivere i componenti per ottenere i numeri di benchmark sopra. `@intlayer/next-intl` è un adattatore plug-and-play: mantiene `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()`, plurali ICU e gli helper di `next-intl/navigation`, e li serve dai dizionari Intlayer compilati dal compilatore Intlayer.
@@ -389,17 +432,84 @@ Consulta la [guida di migrazione next-intl](https://intlayer.org/doc/migration/n
 
 ## Quando scegliere quale?
 
-- **Scegli next-intl** se desideri lo standard dell'ecosistema per Next.js, dipendi da ICU MessageFormat, la tua app è di piccole o medie dimensioni, oppure ti integri con una piattaforma di traduzione (Crowdin, Phrase, Lokalise...) che prevede JSON centralizzati. Prevedi il tempo per namespace dei cataloghi e scegli messaggi per pagina se le prestazioni sono importanti.
-- **Scegli Intlayer** se desideri **contenuto con scope dei componenti**, **strict TypeScript**, **errori di chiavi mancanti in fase di build**, **tree-shaking e lazy loading senza sforzo**, server components sincroni, e tooling editoriale integrato (Visual Editor, CMS, traduzione AI, server MCP). Particolarmente rilevante per codebase grandi e modulari e design systems.
-- **Scegli `@intlayer/next-intl`** se sei già su `next-intl` e desideri i vantaggi di bundle senza una riscrittura completa.
+<AccordionGroup>
+<Accordion header="Scegli next-intl">
+
+Vuoi lo standard dell'ecosistema per Next.js, ti affidi a ICU MessageFormat, la tua app è di dimensioni medio-piccole o ti integri con una piattaforma di traduzione (Crowdin, Phrase, Lokalise...) che prevede JSON centralizzato. Considera il tempo per organizzare i cataloghi in namespace e selezionare i messaggi con `pick()` per pagina se le prestazioni contano.
+
+</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 server sincroni 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 codebase modulari di grandi dimensioni e design system.
+
+</Accordion>
+<Accordion header="Scegli @intlayer/next-intl">
+
+Utilizzi già `next-intl` e desideri i vantaggi in termini di dimensioni del bundle senza dover riscrivere tutto. L'[adattatore di compatibilità](https://intlayer.org/it/doc/compatibility/next-intl) mantiene le importazioni e il file `messages/{locale}.json` come unica fonte di verità. Misurato fianco a fianco in [next-intl vs @intlayer/next-intl](https://intlayer.org/it/blog/next-intl-vs-intlayer-next-intl).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="next-intl è più lento di Intlayer?">
+
+Non al momento del rendering. La differenza risiede in ciò che viene inviato al browser: `next-intl` costa **+12.6 KB gzip** di runtime su ogni pagina e, nelle configurazioni più comuni, invia ~90% delle stringhe di pagine esterne con ogni pagina. Il cambio di lingua e l'idratazione sono paragonabili su Next.js (15-18 ms); su TanStack Start, `use-intl` impiega 7-21 ms contro i 3-4 ms di Intlayer.
+
+</Question>
+
+<Question title="Posso raggiungere lo 0% di dispersione con next-intl?">
+
+Sì, con la configurazione `scoped-dynamic`: dividi `messages/{locale}.json` in un namespace per route, quindi usa `pick(messages, [...])` in ogni pagina e mantieni corretta questa mappatura man mano che i componenti cambiano. Le righe `scoped-*` del benchmark rappresentano proprio questo lavoro. Intlayer raggiunge lo 0% senza tutto questo perché il compilatore isola il contenuto per componente. Consulta [ottimizzazione del bundle](https://intlayer.org/it/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Devo riscrivere i miei componenti per migrare?">
+
+No. `@intlayer/next-intl` mantiene `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()`, i plurali ICU e gli helper di navigazione, e li fornisce da dizionari compilati. Una sola riga di plugin in `next.config.ts`. Passo dopo passo nella [guida alla migrazione di next-intl](https://intlayer.org/it/doc/migration/next-intl).
+
+</Question>
+
+<Question title="Intlayer supporta ICU MessageFormat?">
+
+Il supporto nativo ICU è in fase di sviluppo sull'API principale. Gli adattatori di compatibilità (`@intlayer/next-intl`, `@intlayer/use-intl`) eseguono già ICU: plurali, `select`, `selectordinal`, `#` e `{ts, date, long}` passano attraverso il risolutore ICU di Intlayer. Leggi [formato di messaggio ICU](https://intlayer.org/it/blog/icu-message-format) per i dettagli.
+
+</Question>
+
+<Question title="Posso conservare i miei file messages/{locale}.json?">
+
+Sì. Il [plugin di sincronizzazione JSON](https://intlayer.org/it/doc/compatibility/next-intl) li legge, divide le chiavi di livello superiore in dizionari e riscrive le traduzioni negli stessi file quando la CLI o il CMS li aggiorna. Il flusso di lavoro dei tuoi traduttori non cambia.
+
+</Question>
+
+</FAQ>
 
 ## Confronti correlati
 
-- [i18next vs Intlayer](https://intlayer.org/blog/i18next-vs-intlayer) (stesso benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/blog/lingui-vs-intlayer) (stesso benchmark)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (stesso benchmark)
-- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/blog/next-i18next-vs-next-intl-vs-intlayer)
-- [next-intl è obsoleto?](https://intlayer.org/blog/is-next-intl-outdated)
+Stesso benchmark, altre librerie:
+
+- [i18next vs Intlayer](https://intlayer.org/it/blog/i18next-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)
+
+Approfondimenti su next-intl:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/it/blog/next-intl-vs-intlayer-next-intl), l'adattatore misurato sulla stessa applicazione
+- [Is next-intl outdated?](https://intlayer.org/it/blog/is-next-intl-outdated)
+- [Using Intlayer with next-intl](https://intlayer.org/it/blog/intlayer-with-next-intl)
+- [How to internationalize a Next.js app with next-intl](https://intlayer.org/it/blog/nextjs-internationalization-using-next-intl)
+
+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)
+- [Adattatore di compatibilità: next-intl](https://intlayer.org/it/doc/compatibility/next-intl) e [guida alla migrazione](https://intlayer.org/it/doc/migration/next-intl)
+- [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)
 
 ## Star su GitHub
 

package/blog/it/vue-i18n_vs_intlayer-vue-i18n.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "vue-i18n vs @intlayer/vue-i18n: Stessa API, Bundle Diverso"
 description: Cosa cambia quando un'app Vue 3 mantiene le sue chiamate vue-i18n ma le serve tramite l'adapter di compatibilità @intlayer/vue-i18n. JavaScript per pagina, dimensione runtime, dimensione dei componenti e leakage misurati sullo stesso codice Vite + Vue, più ciò che l'adapter mantiene, ignora e non può sostituire.
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # vue-i18n VS @intlayer/vue-i18n | Stessa API, Bundle Diverso
 
+![Vue i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
 `@intlayer/vue-i18n` è un adapter di compatibilità: espone l'API di `vue-i18n` (`createI18n`, `useI18n`, `t()`, `d()`, `n()`, `$t`, `v-t`, `i18n.global.locale`...) e la serve dai dizionari compilati da Intlayer. I tuoi file `.vue` non cambiano. Cambia solo ciò a cui `t("footer.github")` è associato.
 
 Questo articolo misura tale sostituzione sulla stessa applicazione Vite + Vue 3, costruita una volta con `vue-i18n` e una volta con l'adapter. I numeri provengono da [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Per `vue-i18n` e Intlayer confrontati come librerie, leggi [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) e il [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark). Questo riguarda ciò che l'adapter cambia quando mantieni i tuoi componenti così come sono.
@@ -105,6 +107,10 @@ Per ogni build, la suite registra:
 
 ### Risultati su Vite + Vue 3
 
+Scegli le metriche e le librerie che ti interessano:
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
 | Setup                    | Strategy | Lib size (gz) | Lib size (min) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity |  Page load |
 | ------------------------ | -------- | ------------: | -------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | ---------: |
 | **base** (no i18n)       | -        |        0.0 KB |         0.0 KB |          41.3 KB |        0.0% |         - |             1.1 KB |         1.8 ms |    10.8 ms |
@@ -124,11 +130,24 @@ Per ogni build, la suite registra:
 - **Reattività e caricamento della pagina.** Il cambio di locale è economico per entrambi (1,5-2,8 ms); il sistema di reattività di Vue lo rende così una volta che i messaggi sono in memoria. Il caricamento della pagina passa da 13,6 ms a **9,3 ms**, in linea con 88 KB di JavaScript in meno da analizzare.
 - **Informazioni sulle righe native.** `vue-intlayer` in questa esecuzione ha raggruppato ogni locale in modalità `static` e ha raggiunto 57.1 KB con un runtime di 3.9 KB; i dizionari sincronizzati dell'adapter hanno portato meno stringhe di locale straniere, da qui la cifra più bassa per pagina. Il runtime nativo rimane il più leggero dei tre, e il suo modello `.content.ts` è dove i blocchi SFC `<i18n>` trovano il loro equivalente.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tabella completa, ogni libreria e ogni strategia, nel [report di benchmark Vue](https://intlayer.org/it/doc/benchmark/vue).
+
 ## Perché i numeri cambiano
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Nulla in `src/components/` è cambiato, quindi i miglioramenti provengono da ciò a cui `useI18n` è vincolato.
 
-**Con `vue-i18n`**, il binding è l'istanza globale. `createI18n({ messages: { en, fr, ... } })` è un unico import che contiene tutto; ogni componente che chiama `useI18n()` può accedere a tutto, quindi il bundler non può fare splitting al di sotto dell'istanza. Ottimizzare significa che _tu_ dividi `en.json` per route, chiami `setLocaleMessage()` in un router guard, e mantenere corretta la mappa route-to-file mentre i componenti si muovono.
+**Con `vue-i18n`**, il binding è l'istanza globale. `createI18n({ messages: { en, fr, ... } })` è un unico import che contiene tutto; ogni componente che chiama `useI18n()` può accedere a tutto, quindi il bundler non può fare splitting al di sotto dell'istanza. Ottimizzare significa che _tu_ dividi `en.json` per route, chiami `setLocaleMessage()` in un router guard, e mantenere corretta la mappa route-to-file mentre i componenti si muovono. Lo spreco 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)
 
 ```bash
 .
@@ -258,26 +277,107 @@ export const i18n = createI18n({ locale: "en" });
 
 ## Limiti da conoscere prima di iniziare
 
-- **I blocchi SFC `<i18n>` non vengono letti.** Se i tuoi messaggi risiedono all'interno dei componenti, devono spostarsi nei file locale (o in `.content.ts`, che è la stessa idea con i tipi).
-- **Il caricamento dei messaggi in runtime è scomparso.** `setLocaleMessage()` e `mergeLocaleMessage()` avvisano e tornano. Le traduzioni recuperate da un CMS in runtime hanno bisogno del CMS di Intlayer, o dei comandi `intlayer pull` / `push`.
-- **`messages` è un fallback, non gratuito.** Mantenere gli import JSON in `createI18n()` mantiene i 75 KB nel bundle. Eliminali una volta che `intlayer test` passa.
-- **L'adapter non è il runtime nativo.** 7.9 KB contro 3.9 KB per `vue-intlayer`. Una volta che ogni componente è passato a `useIntlayer`, eliminalo.
+<AccordionGroup>
+<Accordion header="I blocchi SFC <i18n> non vengono letti">
+
+Se i tuoi messaggi si trovano all'interno dei componenti, devono essere spostati nei file di lingua o in un `.content.ts`, che è la stessa idea con tipi generati.
+
+</Accordion>
+<Accordion header="Il caricamento dei messaggi a runtime scompare">
+
+`setLocaleMessage()` e `mergeLocaleMessage()` mostrano un avviso e ritornano. Le traduzioni recuperate da un CMS a runtime richiedono il [CMS Intlayer](https://intlayer.org/it/doc/concept/cms) o i comandi `intlayer pull` / `push`.
+
+</Accordion>
+<Accordion header="messages è un ripiego, non è gratuito">
+
+Mantenere le importazioni JSON in `createI18n()` mantiene i 75 KB nel bundle. Rimuovili una volta superato `intlayer test`.
+
+</Accordion>
+<Accordion header="L'adattatore non è il runtime nativo">
+
+7.9 KB contro 3.9 KB per `vue-intlayer`. Una volta che ogni componente è passato a `useIntlayer`, rimuovilo.
+
+</Accordion>
+</AccordionGroup>
 
 ## Quando usare quale?
 
-- **Rimani su `vue-i18n`** se la tua app dipende dai blocchi `<i18n>` SFC, dai flussi `setLocaleMessage()` a runtime, o se 90 KB per pagina non è una preoccupazione per il tuo pubblico.
-- **Usa `@intlayer/vue-i18n`** se sei su `vue-i18n` e vuoi i 88 KB, i componenti 23 volte più piccoli, 0% page leakage, chiavi tipizzate e controlli CI senza modificare un file `.vue`. Questo è il punto di ingresso per una codebase `vue-i18n` esistente.
-- **Vai nativo (`vue-intlayer`)** per i nuovi progetti, o una volta che l'adapter ha fatto il suo lavoro. Ha il runtime più leggero (3.9 KB) e il modello `.content.ts` per componente che sostituisce i blocchi `<i18n>` con contenuto tipizzato.
+<AccordionGroup>
+<Accordion header="Rimanere su vue-i18n">
+
+La tua applicazione dipende dai blocchi SFC `<i18n>`, da flussi `setLocaleMessage()` a runtime, o 90 KB per pagina non rappresentano un problema per il tuo pubblico.
+
+</Accordion>
+<Accordion header="Usare @intlayer/vue-i18n">
+
+Usi `vue-i18n` e vuoi gli 88 KB risparmiati, componenti 23 volte più piccoli, 0% di dispersione di pagina, chiavi tipizzate e controlli CI senza toccare un file `.vue`. Questo è il punto di ingresso per una codebase `vue-i18n` esistente.
+
+</Accordion>
+<Accordion header="Passare a nativo (vue-intlayer)">
+
+Per nuovi progetti, o una volta che l'adattatore ha completato il suo compito. Offre il runtime più leggero (3.9 KB) e il modello `.content.ts` per componente che sostituisce i blocchi `<i18n>` con contenuti tipizzati. Inizia con [Intlayer con Vue](https://intlayer.org/it/doc/environment/vite-and-vue) o [con Nuxt](https://intlayer.org/it/doc/environment/nuxt-and-vue).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Devo modificare i miei file .vue?">
+
+No. La build di benchmark ha modificato solo `vite.config.ts`, `intlayer.config.ts` e una riga in `src/i18n.ts`, l'importazione di `messages`. Ogni chiamata a `useI18n()`, `$t`, `v-t` e all'Options API è rimasta identica.
+
+</Question>
+
+<Question title="Perché la dimensione dei componenti è 23 volte inferiore?">
+
+Perché `useI18n()` smette di fare riferimento all'istanza globale. `createI18n({ messages })` contiene tutti i messaggi di tutte le lingue, quindi un componente compilato isolatamente trascina 196 KB. Con l'adattatore accede solo al proprio dizionario: 8.4 KB.
+
+</Question>
+
+<Question title="Cosa succede con la formattazione di d() e n()?">
+
+Mantenuta. Le configurazioni `datetimeFormats` e `numberFormats` passate a `createI18n()` sono rispettate, supportate dalle API native `Intl`. Consulta [formattazione di date, ore e numeri](https://intlayer.org/it/blog/date-time-number-formatting-locales).
+
+</Question>
+
+<Question title="Funziona con Nuxt?">
+
+`@intlayer/vue-i18n` è destinato a Vite + Vue. Per `@nuxtjs/i18n`, usa l'[adattatore di compatibilità Nuxt i18n](https://intlayer.org/it/doc/compatibility/nuxtjs-i18n) e consulta [Intlayer con Nuxt](https://intlayer.org/it/doc/environment/nuxt-and-vue) per la configurazione nativa.
+
+</Question>
+
+<Question title="Posso migrare componente per componente?">
+
+Sì. Qualsiasi componente può passare da `useI18n()` a `useIntlayer("footer")` con un file di contenuto collocato accanto. I dizionari JSON e `.content.ts` coesistono e si uniscono.
+
+</Question>
+
+</FAQ>
 
 ## Confronti correlati
 
-- [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) (funzionalità e DX)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (le librerie, stesso benchmark)
-- [next-intl vs @intlayer/next-intl](https://intlayer.org/blog/next-intl-vs-intlayer-next-intl) (stessa serie di adapter)
-- [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)
-- [Guida alla migrazione: vue-i18n a Intlayer](https://intlayer.org/doc/migration/vue-i18n)
-- [Riferimento dell'adattatore di compatibilità: vue-i18n](https://intlayer.org/doc/compatibility/vue-i18n), [Nuxt i18n](https://intlayer.org/doc/compatibility/nuxtjs-i18n)
+Stessa serie di adattatori:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/it/blog/next-intl-vs-intlayer-next-intl)
+- [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)
+
+Le librerie a confronto diretto:
+
+- [vue-i18n vs Intlayer](https://intlayer.org/it/blog/vue-i18n-vs-intlayer), funzionalità e DX
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/it/blog/vue-i18n-vs-intlayer-benchmark)
+- [Is vue-i18n outdated?](https://intlayer.org/it/blog/is-vue-i18n-outdated)
+- [How to pick a Vue i18n library](https://intlayer.org/it/blog/how-to-pick-vue-i18n-library)
+
+Documentazione di riferimento:
+
+- [Compat adapter: vue-i18n](https://intlayer.org/it/doc/compatibility/vue-i18n) and [Nuxt i18n](https://intlayer.org/it/doc/compatibility/nuxtjs-i18n)
+- [Guida alla migrazione: da vue-i18n a Intlayer](https://intlayer.org/it/doc/migration/vue-i18n)
+- [Report di benchmark Vue](https://intlayer.org/it/doc/benchmark/vue)
+- [Ottimizzazione del bundle](https://intlayer.org/it/doc/concept/bundle-optimization) e [il compilatore Intlayer](https://intlayer.org/it/doc/compiler)
+- [Visual Editor](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
 
@@ -285,4 +385,4 @@ export const i18n = createI18n({ locale: "en" });
 
 Tutti i dati grezzi, le app di test e gli script si trovano nel [repository Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Eseguilo tu stesso.
 
-Consulta la documentazione ['Why Intlayer?'](https://intlayer.org/doc/why) per maggiori dettagli.
+Consulta la documentazione ['Why Intlayer?'](https://intlayer.org/it/doc/why) per maggiori dettagli.