@intlayer/docs 8.9.4 → 8.9.6-canary.0

package/docs/it/benchmark/nextjs.md

@@ -61,6 +61,13 @@ Poiché il problema è difficile, esistono molte soluzioni, alcune focalizzate s
 
 Intlayer cerca di ottimizzare tutte queste dimensioni.
 
+## TL;DR
+
+- **Intlayer** e **next-translate**: Le migliori scelte per le prestazioni di Next.js, con l'impronta minima e il miglior supporto al rendering statico.
+- **next-intl**: L'opzione più di tendenza, ma pesante e complessa da ottimizzare per grandi applicazioni.
+- **next-i18next**: Popolare e ricca di plugin, ma comporta un peso del bundle significativo (~3× Intlayer).
+- **Da evitare**: **gt-next** e **lingo.dev** a causa di gravi problemi di prestazioni, vendor lock-in ed errori che bloccano la build.
+
 ## Testa la tua app
 
 Per far emergere questi problemi, ho creato uno scanner gratuito che puoi provare [qui](https://intlayer.org/i18n-seo-scanner).
@@ -99,14 +106,14 @@ Infine, `Intlayer` applica un'ottimizzazione build-time in modo che `useIntlayer
 Per questo benchmark, abbiamo confrontato le seguenti librerie:
 
 - `Base App` (Nessuna libreria i18n)
-- `next-intlayer` (v8.7.5)
+- `next-intlayer` (v8.7.12)
 - `next-i18next` (v16.0.5)
 - `next-intl` (v4.9.1)
 - `@lingui/core` (v5.3.0)
 - `next-translate` (v3.1.2)
 - `next-international` (v1.3.1)
 - `@inlang/paraglide-js` (v2.15.1)
-- `tolgee` (v7.0.0)
+- `@tolgee/react` (v7.0.0)
 - `@lingo.dev/compiler` (v0.4.0)
 - `wuchale` (v0.22.11)
 - `gt-next` (v6.16.5)
@@ -161,10 +168,10 @@ Problemi riscontrati:
 
 **(General Translation)** (`gt-next@6.16.5`):
 
-- Per un'app da 110kb, `gt-react` aggiunge più di 440kb extra.
+- Per un'app da 110kb, `gt-next` aggiunge più di 440kb extra.
 - `Quota Exceeded, please upgrade your plan` al primissimo build con General Translation.
 - Le traduzioni non vengono renderizzate; ottengo l'errore `Error: <T> used on the client-side outside of <GTProvider>`, che sembra essere un bug nella libreria.
-- Durante l'implementazione di **gt-tanstack-start-react**, ho riscontrato anche un [problema](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) con la libreria: `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, che faceva fallire l'applicazione. Dopo aver segnalato questo problema, il manutentore lo ha risolto entro 24 ore.
+- Durante l'implementazione di **gt-next**, ho riscontrato anche un [problema](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) con la libreria: `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, che faceva fallire l'applicazione. Dopo aver segnalato questo problema, il manutentore lo ha risolto entro 24 ore.
 - La libreria blocca il rendering statico delle pagine Next.js.
 
 **(Lingo.dev)** (`@lingo.dev/compiler@0.4.0`):
@@ -186,9 +193,11 @@ L'idea alla base di `Wuchale` è interessante ma non ancora praticabile. Ho risc
 Personalmente non mi piace dover rigenerare file JS prima di ogni push, il che crea un rischio costante di conflitti di merge tramite PR. Lo strumento sembra inoltre più focalizzato su Vite che su Next.js.
 Infine, rispetto ad altre soluzioni, Paraglide non usa uno store (es. contesto React) per recuperare la lingua corrente per renderizzare il contenuto. Per ogni nodo analizzato, richiederà la lingua da localStorage / cookie ecc. Ciò porta all'esecuzione di logica non necessaria che impatta sulla reattività del componente.
 
+> Nota su paraglide: la soluzione inietta codice nella tua codebase per l'importazione, di conseguenza la metrica 'dimensione della lib' nel report benchmark è quasi 0. La generazione del codice è un aspetto positivo, poiché la funzione utilizzata includerà solo la lógica necessaria (prefisso totale vs nessun prefisso, cookie vs storage, ecc.). In confronto, Intlayer esegue questo filtraggio tramite iniezioni di variabili d'ambiente nella build per forzare il bundler a scartare i contenuti in base alla logica. Grazie a ciò, paraglide e intlayer risultano soluzioni da 6 a 10 volte più leggere rispetto a i18next o next-intl.
+
 ### 3 — Soluzioni accettabili
 
-**(Tolgee)** (`tolgee@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.0.0`):
 
 `Tolgee` affronta molti dei problemi menzionati in precedenza. L'ho trovato più difficile da adottare rispetto a strumenti simili. Non fornisce type safety, il che rende anche più difficile individuare le chiavi mancanti a compile time. Ho dovuto avvolgere le funzioni di Tolgee con le mie per aggiungere il rilevamento delle chiavi mancanti.
 
@@ -216,7 +225,7 @@ I formati dei messaggi differiscono inoltre: `next-intl` usa ICU MessageFormat,
 
 `next-translate` è la mia raccomandazione principale se ti piace un'API in stile `t()`. È elegante grazie a `next-translate-plugin`, caricando i namespace attraverso `getStaticProps` con un caricatore Webpack / Turbopack. È anche l'opzione più leggera qui (~2.5kb). Per il namespacing, la definizione dei namespace per pagina o percorso nella config è ben pensata e più facile da mantenere rispetto alle principali alternative come **next-intl** o **next-i18next**. Nella versione `3.1.2`, ho notato che il rendering statico non funzionava; Next.js ripiegava sul rendering dinamico.
 
-**(Intlayer)** (`next-intlayer@8.7.5`):
+**(Intlayer)** (`next-intlayer@8.7.12`):
 
 Non giudicherò personalmente `next-intlayer` per motivi di obiettività, essendo la mia propria soluzione.
 

package/docs/it/benchmark/solid.md

@@ -0,0 +1,155 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: Migliore soluzione i18n per Solid nel 2026 - Rapporto Benchmark
+description: Confronta le librerie di internazionalizzazione (i18n) per Solid come solid-primitives, solid-i18next e Intlayer. Rapporto dettagliato sulle prestazioni in termini di dimensioni del bundle, leak e reattività.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - solid
+  - prestazioni
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - solid
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Inizializzazione del benchmark"
+---
+
+# Librerie i18n per Solid — Rapporto Benchmark 2026
+
+Questa pagina è un rapporto di benchmark per le soluzioni i18n su Solid.
+
+## Sommario
+
+<Toc/>
+
+## Benchmark Interattivo
+
+<I18nBenchmark framework="vite-solid" vertical/>
+
+## Riferimento dei risultati:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md
+
+Vedi il repository completo del benchmark [qui](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Introduzione
+
+Le soluzioni di internazionalizzazione sono tra le dipendenze più pesanti in un'app Solid. Il rischio principale è l'invio di contenuti non necessari: traduzioni per altre pagine e altre lingue nel bundle di una singola rotta.
+
+Man mano che l'app cresce, questo problema può far esplodere rapidamente il JavaScript inviato al client e rallentare la navigazione.
+
+In pratica, per le implementazioni meno ottimizzate, una pagina internazionalizzata può finire per essere diverse volte più pesante della versione senza i18n.
+
+L'autre impatto riguarda l'esperienza dello sviluppatore (DX): come si dichiara il contenuto, i tipi, l'organizzazione dei namespace, il caricamento dinamico e la reattività al cambio di lingua.
+
+## TL;DR
+
+- **Intlayer**: Scelta consigliata per applicazioni Solid professionali che necessitano di funzionalità avanzate e ottimizzazione (v8.7.12).
+- **@solid-primitives/i18n**: Eccellente alternativa leggera per progetti semplici, sebbene manchi di funzionalità avanzate come il lazy loading.
+- **solid-i18next**: Opzione standard ma pesante (~4.7× Intlayer) con gli stessi svantaggi di React i18next.
+- **Paraglide**: Approccio innovativo ma DX complessa e problemi di tree-shaking in alcune configurazioni.
+
+## Testa la tua app
+
+Per individuare rapidamente i problemi di leak i18n, ho configurato uno scanner gratuito disponibile [qui](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Il problema
+
+Due leve sono essenziali per limitare il costo di un'app multilingue:
+
+- Dividere il contenuto per pagina / namespace per non caricare interi dizionari quando non servono.
+- Caricare la lingua corretta in modo dinamico, solo quando necessario.
+
+Comprendere i limiti tecnici di questi approcci:
+
+**Caricamento dinamico**
+
+Senza caricamento dinamico, la maggior parte delle soluzioni mantiene i messaggi in memoria fin dal primo render, aggiungendo un overhead significativo per le app con molte rotte e lingue.
+
+Con il caricamento dinamico, si accetta un compromesso: meno JS iniziale, ma a volte una richiesta extra quando si cambia lingua.
+
+**Divisione dei contenuti (Splitting)**
+
+Le sintassi costruite attorno a `t('a.b.c')` sono molto comode ma spesso incoraggiano a mantenere grandi oggetti JSON a runtime. Questo modello rende difficile il tree-shaking a meno che la libreria non offra una reale strategia di divisione per pagina.
+
+## Metodologia
+
+Per questo benchmark, abbiamo confrontato le seguenti librerie:
+
+- `Base App` (Nessuna libreria i18n)
+- `solid-intlayer` (v8.7.12)
+- `@solid-primitives/i18n` (v2.2.1)
+- `solid-i18next` (v17.0.2)
+- `@inlang/paraglide-js` (v2.17.0)
+
+Il framework è `Solid` con un'app multilingue di **10 pagine** e **10 lingue**.
+
+Abbiamo confrontato **quattro strategie di caricamento**:
+
+| Strategia                | Senza namespace (globale)                      | Con namespace (scoped)                                             |
+| :----------------------- | :--------------------------------------------- | :----------------------------------------------------------------- |
+| **Caricamento statico**  | **Static**: Tutto in memoria all'avvio.        | **Scoped static**: Diviso per namespace; tutto caricato all'avvio. |
+| **Caricamento dinamico** | **Dynamic**: Caricamento on-demand per lingua. | **Scoped dynamic**: Caricamento granulare per namespace e lingua.  |
+
+## Riepilogo delle strategie
+
+- **Static**: Semplice; nessuna latenza di rete dopo il caricamento iniziale. Svantaggio: grandi dimensioni del bundle.
+- **Dynamic**: Riduce il peso iniziale (lazy-loading). Ideale quando si hanno molte lingue.
+- **Scoped static**: Mantiene il codice organizzato (separazione logica) senza complesse richieste di rete extra.
+- **Scoped dynamic**: Il miglior approccio per il _code splitting_ e le prestazioni. Minimizza la memoria caricando solo ciò di cui la vista corrente e la lingua attiva hanno bisogno.
+
+## Risultati in dettaglio
+
+### 1 — Soluzioni da evitare
+
+> Nessuna soluzione chiara da evitare nell'ecosistema Solid.
+
+### 2 — Soluzioni accettabili
+
+**(solid-i18next)** (`solid-i18next@17.0.2`):
+
+`solid-i18next` è probabilmente l'opzione più popolare perché è stata tra le prime a soddisfare le esigenze i18n delle app JavaScript. Dispone inoltre di un ampio set di plugin della comunità per problemi specifici.
+
+Il pacchetto è pesante (~14.6kb, circa 4.7 volte `solid-intlayer`).
+
+Tuttavia, condivide gli stessi principali svantaggi degli stack costruiti su `t('a.b.c')`: le ottimizzazioni sono possibili ma richiedono molto tempo, e i grandi progetti rischiano cattive pratiche (namespace + caricamento dinamico + tipi).
+
+**(@solid-primitives/i18n)** (`@solid-primitives/i18n@2.2.1`):
+
+Solid primitive è estremamente leggero ed efficiente. Consiglio questa soluzione per progetti leggeri, ma può mancare rapidamente di funzionalità per soluzioni professionali incluse la gestione dei cookie, il reindirizzamento proxy, i formattatori ecc.
+Manca inoltre del lazy loading e dello scoping dei namespace per l'ottimizzazione delle dimensioni della pagina.
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+`Paraglide` offre un approccio innovativo e ben ponderato. Tuttavia, in questo benchmark il tree-shaking pubblicizzato dalla loro azienda non ha funzionato per la mia implementazione. Il workflow e la DX sono inoltre più complessi rispetto ad altre opzioni.
+Personalmente, non amo dover rigenerare file JS prima di ogni push, il che crea un costante rischio di conflitti di merge tramite le PR.
+Infine, rispetto ad altre soluzioni, Paraglide non utilizza uno store (es. Solid signal) per recuperare la lingua corrente per renderizzare il contenuto. Per ogni nodo analizzato, richiederà la lingua al localStorage / cookie ecc. Ciò porta all'esecuzione di logica non necessaria che impatta sulla reattività del componente.
+
+### 3 — Raccomandazioni
+
+**(Intlayer)** (`solid-intlayer@8.7.12`):
+
+Non giudicherò personalmente `solid-intlayer` per motivi di obiettività, essendo la mia soluzione.
+
+### Nota personale
+
+Questa nota è personale e non influisce sui risultati del benchmark. Tuttavia, nel mondo i18n si vede spesso un consenso attorno a un pattern come `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` per i contenuti tradotti.
+
+Nelle app Solid, iniettare una funzione come `JSX.Element` è, a mio avviso, un anti-pattern. Aggiunge inoltre una complessità evitabile e un overhead di esecuzione JavaScript (anche se appena percettibile).

package/docs/it/benchmark/svelte.md

@@ -0,0 +1,148 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: Migliore soluzione i18n per Svelte nel 2026 - Rapporto Benchmark
+description: Confronta le librerie di internazionalizzazione (i18n) per Svelte come svelte-i18n, Paraglide e Intlayer. Rapporto dettagliato sulle prestazioni in termini di dimensioni del bundle, leak e reattività.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - svelte
+  - prestazioni
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - svelte
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Inizializzazione del benchmark"
+---
+
+# Librerie i18n per Svelte — Rapporto Benchmark 2026
+
+Questa pagina è un rapporto di benchmark per le soluzioni i18n su Svelte.
+
+## Sommario
+
+<Toc/>
+
+## Benchmark Interattivo
+
+<I18nBenchmark framework="vite-svelte" vertical/>
+
+## Riferimento dei risultati:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md
+
+Vedi il repository completo del benchmark [qui](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Introduzione
+
+Le soluzioni di internazionalizzazione sono tra le dipendenze più pesanti in un'app Svelte. Il rischio principale è l'invio di contenuti non necessari: traduzioni per altre pagine e altre lingue nel bundle di una singola rotta.
+
+Man mano che l'app cresce, questo problema può far esplodere rapidamente il JavaScript inviato al client e rallentare la navigazione.
+
+In pratica, per le implementazioni meno ottimizzate, una pagina internazionalizzata può finire per essere diverse volte più pesante della versione senza i18n.
+
+L'altro impatto riguarda l'esperienza dello sviluppatore (DX): come si dichiara il contenuto, i tipi, l'organizzazione dei namespace, il caricamento dinamico e la reattività al cambio di lingua.
+
+## TL;DR
+
+- **Intlayer**: La scelta più efficiente in termini di prestazioni (v8.7.12) con il footprint più ridotto.
+- **Paraglide**: Forte candidato per il tree-shaking ma presenta una DX più complessa e un overhead di reattività.
+- **svelte-i18n**: Completo e standard per Svelte, ma comporta un peso del bundle molto maggiore (~7 volte Intlayer).
+
+## Testa la tua app
+
+Per individuare rapidamente i problemi di leak i18n, ho configurato uno scanner gratuito disponibile [qui](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Il problema
+
+Due leve sono essenziali per limitare il costo di un'app multilingue:
+
+- Dividere il contenuto per pagina / namespace per non caricare interi dizionari quando non servono.
+- Caricare la lingua corretta in modo dinamico, solo quando necessario.
+
+Comprendere i limiti tecnici di questi approcci:
+
+**Caricamento dinamico**
+
+Senza caricamento dinamico, la maggior parte delle soluzioni mantiene i messaggi in memoria fin dal primo render, aggiungendo un overhead significativo per le app con molte rotte e lingue.
+
+Con il caricamento dinamico, si accetta un compromesso: meno JS iniziale, ma a volte una richiesta extra quando si cambia lingua.
+
+**Divisione dei contenuti (Splitting)**
+
+Le sintassi costruite attorno a `t('a.b.c')` sono molto comode ma spesso incoraggiano a mantenere grandi oggetti JSON a runtime. Questo modello rende difficile il tree-shaking a meno che la libreria non offra una reale strategia di divisione per pagina.
+
+## Metodologia
+
+Per questo benchmark, abbiamo confrontato le seguenti librerie:
+
+- `Base App` (Nessuna libreria i18n)
+- `svelte-intlayer` (v8.7.12)
+- `svelte-i18n` (v4.0.1)
+- `@inlang/paraglide-js` (v2.17.0)
+
+Il framework è `Svelte` con un'app multilingue di **10 pagine** e **10 lingue**.
+
+Abbiamo confrontato **quattro strategie di caricamento**:
+
+| Strategia                | Senza namespace (globale)                      | Con namespace (scoped)                                             |
+| :----------------------- | :--------------------------------------------- | :----------------------------------------------------------------- |
+| **Caricamento statico**  | **Static**: Tutto in memoria all'avvio.        | **Scoped static**: Diviso per namespace; tutto caricato all'avvio. |
+| **Caricamento dinamico** | **Dynamic**: Caricamento on-demand per lingua. | **Scoped dynamic**: Caricamento granulare per namespace e lingua.  |
+
+## Riepilogo delle strategie
+
+- **Static**: Semplice; nessuna latenza di rete dopo il caricamento iniziale. Svantaggio: grandi dimensioni del bundle.
+- **Dynamic**: Riduce il peso iniziale (lazy-loading). Ideale quando si hanno molte lingue.
+- **Scoped static**: Mantiene il codice organizzato (separazione logica) senza complesse richieste di rete extra.
+- **Scoped dynamic**: Il miglior approccio per il _code splitting_ e le prestazioni. Minimizza la memoria caricando solo ciò di cui la vista corrente e la lingua attiva hanno bisogno.
+
+## Risultati in dettaglio
+
+### 1 — Soluzioni da evitare
+
+> Nessuna soluzione chiara da evitare nell'ecosistema Svelte.
+
+### 2 — Soluzioni accettabili
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+`Paraglide` offre un approccio innovativo e ben ponderato. Nel contesto di un'app Vite + Svelte, il tree-shaking pubblicizzato dalla loro azienda funziona come previsto, il che è eccellente.
+Ma nel caso di React + TanStack Start, il tree-shaking non ha funzionato come previsto, così come per Next.js. Detto questo, l'uso di Paraglide in un progetto Svelte e TanStack Start meriterebbe una verifica più approfondita.
+Il workflow e la DX sono inoltre più complessi rispetto ad altre opzioni.
+Personalmente, non amo dover rigenerare file JS prima di ogni push, il che crea un costante rischio di conflitti di merge tramite le PR. Lo strumento sembra inoltre più focalizzato su Vite che su Next.js.
+Infine, rispetto ad altre soluzioni, Paraglide non utilizza uno store (es. Svelte store) per recuperare la lingua corrente per renderizzare il contenuto. Per ogni nodo analizzato, richiederà la lingua al localStorage / cookie ecc. Ciò porta all'esecuzione di logica non necessaria che impatta sulla reattività del componente.
+
+> Nota su Paraglide: la soluzione inietta codice nella tua codebase per gli import; di conseguenza, la metrica 'lib size' nel rapporto benchmark è quasi 0. La generazione di codice è una cosa buona, perché la funzione utilizzata includerà solo la logica necessaria (prefisso ovunque vs nessun prefisso, cookie vs storage, ecc.). In confronto, Intlayer esegue questo filtraggio tramite iniezioni di variabili d'ambiente durante la build per forzare il bundler a fare tree-shaking del contenuto a seconda della logica. Grazie a ciò, Paraglide e Intlayer finiscono per essere soluzioni da 6 a 10 volte più leggere di i18next o next-intl.
+
+**(svelte-i18n)** (`svelte-i18n@3.4.0`):
+
+Questa soluzione soddisfa tutte le esigenze i18n in un progetto Svelte. Ma come per i18next o altre importanti soluzioni i18n, è un po' pesante (~15.9kb, circa 7 volte `svelte-intlayer`).
+
+### 3 — Raccomandazioni
+
+**(Intlayer)** (`svelte-intlayer@8.7.12`):
+
+Non giudicherò personalmente `svelte-intlayer` per motivi di obiettività, essendo la mia soluzione.
+
+### Nota personale
+
+Questa nota è personale e non influisce sui risultati del benchmark. Tuttavia, nel mondo i18n si vede spesso un consenso attorno a un pattern come `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` per i contenuti tradotti.
+
+Nelle app Svelte, iniettare una funzione come `Slot` è, a mio avviso, un anti-pattern. Aggiunge inoltre una complessità evitabile e un overhead di esecuzione JavaScript (anche se appena percettibile).

package/docs/it/benchmark/tanstack.md

@@ -57,6 +57,13 @@ In pratica, per le implementazioni meno ottimizzate, una pagina internazionalizz
 
 L'altro impatto riguarda la developer experience (DX): come si dichiara il contenuto, i tipi, l'organizzazione dei namespace, il caricamento dinamico e la reattività al cambio di lingua.
 
+## TL;DR
+
+- **Intlayer**: Fornisce le migliori prestazioni e la dimensione del bundle più ridotta (v8.7.12) per TanStack Start.
+- **react-i18next** & **use-intl**: Alternative mature con ecosistemi ampi, ma significativamente più pesanti e complesse da ottimizzare.
+- **Paraglide**: Idea innovativa di tree-shaking che non funziona nella pratica. DX complessa e sovraccarico di reattività in TanStack Start.
+- **Da evitare**: **General Translation (GT)** e **Lingo.dev** a causa di gravi problemi di prestazioni, limiti di quota AI e vendor lock-in.
+
 ## Testa la tua app
 
 Per individuare rapidamente problemi di leakage i18n, ho configurato uno scanner gratuito disponibile [qui](https://intlayer.org/i18n-seo-scanner).
@@ -87,12 +94,12 @@ Le sintassi costruite attorno a `const t = useTranslation()` + `t('a.b.c')` sono
 Per questo benchmark, abbiamo confrontato le seguenti librerie:
 
 - `Base App` (Nessuna libreria i18n)
-- `react-intlayer` (v8.7.5-canary.0)
+- `react-intlayer` (v8.7.12)
 - `react-i18next` (v17.0.2)
 - `use-intl` (v4.9.1)
 - `@lingui/core` (v5.3.0)
 - `@inlang/paraglide-js` (v2.15.1)
-- `tolgee` (v7.0.0)
+- `@tolgee/react` (v7.0.0)
 - `react-intl` (v10.1.1)
 - `wuchale` (v0.22.11)
 - `gt-react` (vlatest)
@@ -150,7 +157,9 @@ L'idea alla base di `Wuchale` è interessante ma non ancora una soluzione pratic
 
 `Paraglide` offre un approccio innovativo e ben ponderato. Tuttavia, in questo benchmark il tree-shaking pubblicizzato non ha funzionato per la mia implementazione Next.js o per TanStack Start. Il workflow e la DX sono inoltre più complessi di altre opzioni. Personalmente non sono un fan del dover rigenerare file JS prima di ogni push, il che crea un rischio costante di conflitti di merge per gli sviluppatori tramite PR.
 
-**(Tolgee)** (`tolgee@7.0.0`):
+> Nota su paraglide: questa soluzione inietta codice nella tua base di codice per le importazioni; di conseguenza, la metrica 'lib size' nel rapporto benchmark è quasi 0. La generazione del codice è un aspetto positivo, poiché la funzione utilizzata includerà solo la logica necessaria (prefisso ovunque vs nessun prefisso, cookie vs storage, ecc.). Al contrario, Intlayer esegue questo filtraggio tramite iniezioni di variabili d'ambiente nella build per forzare il bundler a eseguire il tree-shaking del contenuto in base alla logica. Grazie a ciò, paraglide e intlayer risultano soluzioni da 6 a 10 volte più leggere rispetto a i18next o next-intl.
+
+**(Tolgee)** (`@tolgee/react@7.0.0`):
 
 `Tolgee` affronta molti dei problemi menzionati in precedenza. L'ho trovato più difficile da avviare rispetto ad altri strumenti con approcci simili. Non fornisce type safety, il che rende anche molto difficile individuare le chiavi mancanti a compile time. Ho dovuto avvolgere le API di Tolgee con le mie per aggiungere il rilevamento delle chiavi mancanti.
 

package/docs/it/benchmark/vue.md

@@ -0,0 +1,160 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: Migliore soluzione i18n per Vue nel 2026 - Rapporto Benchmark
+description: Confronta le librerie di internazionalizzazione (i18n) per Vue come vue-i18n, fluent-vue e Intlayer. Rapporto dettagliato sulle prestazioni in termini di dimensioni del bundle, leak e reattività.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - vue
+  - prestazioni
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - vue
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Inizializzazione del benchmark"
+---
+
+# Librerie i18n per Vue — Rapporto Benchmark 2026
+
+Questa pagina è un rapporto di benchmark per le soluzioni i18n su Vue.
+
+## Sommario
+
+<Toc/>
+
+## Benchmark Interattivo
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
+## Riferimento dei risultati:
+
+<iframe 
+  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;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md
+
+Vedi il repository completo del benchmark [qui](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Introduzione
+
+Le soluzioni di internazionalizzazione sono tra le dipendenze più pesanti in un'app Vue. Il rischio principale è l'invio di contenuti non necessari: traduzioni per altre pagine e altre lingue nel bundle di una singola rotta.
+
+Man mano che l'app cresce, questo problema può far esplodere rapidamente il JavaScript inviato al client e rallentare la navigazione.
+
+In pratica, per le implementazioni meno ottimizzate, una pagina internazionalizzata può finire per essere diverse volte più pesante della versione senza i18n.
+
+L'altro impatto riguarda l'esperienza dello sviluppatore (DX): come si dichiara il contenuto, i tipi, l'organizzazione dei namespace, il caricamento dinamico e la reattività al cambio di lingua.
+
+## TL;DR
+
+- **Intlayer**: La soluzione più leggera (v8.7.12) con scoping e caricamento dinamico nativi.
+- **vue-i18n**: Lo standard del settore con un ricco ecosistema, ma può essere significativamente più pesante e difficile da ottimizzare per il code-splitting in applicazioni di grandi dimensioni.
+- **fluent-vue**: Organizzazione dei messaggi innovativa ma manca di type-safety e risulta essere una soluzione estremamente pesante.
+
+## Testa la tua app
+
+Per individuare rapidamente i problemi di leak i18n, ho configurato uno scanner gratuito disponibile [qui](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Il problema
+
+Due leve sono essenziali per limitare il costo di un'app multilingue:
+
+- Dividere il contenuto per pagina / namespace per non caricare interi dizionari quando non servono.
+- Caricare la lingua corretta in modo dinamico, solo quando necessario.
+
+Comprendere i limiti tecnici di questi approcci:
+
+**Caricamento dinamico**
+
+Senza caricamento dinamico, la maggior parte delle soluzioni mantiene i messaggi in memoria fin dal primo render, aggiungendo un overhead significativo per le app con molte rotte e lingue.
+
+Con il caricamento dinamico, si accetta un compromesso: meno JS iniziale, ma a volte una richiesta extra quando si cambia lingua.
+
+**Divisione dei contenuti (Splitting)**
+
+Le sintassi costruite attorno a `const { t } = useI18n()` + `t('a.b.c')` sono molto comode ma spesso incoraggiano a mantenere grandi oggetti JSON a runtime. Questo modello rende difficile il tree-shaking a meno che la libreria non offra una reale strategia di divisione per pagina.
+
+## Metodologia
+
+Per questo benchmark, abbiamo confrontato le seguenti librerie:
+
+- `Base App` (Nessuna libreria i18n)
+- `vue-intlayer` (v8.7.12)
+- `vue-i18n` (v11.4.0)
+- `fluent-vue` (v3.8.2)
+
+Il framework è `Vue` con un'app multilingue di **10 pagine** e **10 lingue**.
+
+Abbiamo confrontato **quattro strategie di caricamento**:
+
+| Strategia                | Senza namespace (globale)                      | Con namespace (scoped)                                             |
+| :----------------------- | :--------------------------------------------- | :----------------------------------------------------------------- |
+| **Caricamento statico**  | **Static**: Tutto in memoria all'avvio.        | **Scoped static**: Diviso per namespace; tutto caricato all'avvio. |
+| **Caricamento dinamico** | **Dynamic**: Caricamento on-demand per lingua. | **Scoped dynamic**: Caricamento granulare per namespace e lingua.  |
+
+## Riepilogo delle strategie
+
+- **Static**: Semplice; nessuna latenza di rete dopo il caricamento iniziale. Svantaggio: grandi dimensioni del bundle.
+- **Dynamic**: Riduce il peso iniziale (lazy-loading). Ideale quando si hanno molte lingue.
+- **Scoped static**: Mantiene il codice organizzato (separazione logica) senza complesse richieste di rete extra.
+- **Scoped dynamic**: Il miglior approccio per il _code splitting_ e le prestazioni. Minimizza la memoria caricando solo ciò di cui la vista corrente e la lingua attiva hanno bisogno.
+
+### Cosa ho misurato:
+
+Ho eseguito la stessa app multilingue in un browser reale per ogni stack, poi ho annotato cosa passava effettivamente sulla rete e quanto tempo richiedevano le operazioni. Le dimensioni sono riportate **dopo la normale compressione web**, perché è più vicino a ciò che le persone scaricano effettivamente.
+
+- **Dimensioni della libreria di internazionalizzazione**: Dopo il bundling, il tree-shaking e la minificazione, la dimensione della libreria i18n è la dimensione del codice dei provider + composable in un componente vuoto. Non include il caricamento dei file di traduzione. Risponde a quanto è "costosa" la libreria prima che entri in gioco il tuo contenuto.
+
+- **JavaScript per pagina**: Per ogni rotta del benchmark, quanto script viene scaricato dal browser per quella visita, mediato tra le pagine della suite (e tra le lingue). Le pagine pesanti sono pagine lente.
+
+- **Leak da altre lingue (Leakage)**: È il contenuto della stessa pagina ma in un'altra lingua che verrebbe caricato per errore nella pagina verificata. Questo contenuto è inutile e dovrebbe essere evitato (es. contenuto della pagina `/fr/about` nel bundle della pagina `/en/about`).
+
+- **Leak da altre rotte**: La stessa idea per **altre schermate** nell'app: se i loro testi vengono caricati quando hai aperto solo una pagina (es. contenuto della pagina `/en/about` nel bundle della pagina `/en/contact`). Un punteggio alto indica una divisione debole o bundle troppo ampi.
+
+- **Dimensione media del bundle del componente**: Gli elementi UI comuni vengono misurati **uno alla volta**, invece di nascondersi all'interno di un unico numero gigante dell'app. Mostra se l'internazionalizzazione gonfia silenziosamente i componenti quotidiani. Ad esempio, se il tuo componente viene renderizzato di nuovo, caricherà tutti quei dati dalla memoria. Allegare un JSON gigante a qualsiasi componente è come collegare un grande magazzino di dati inutilizzati che rallenterà le prestazioni dei tuoi componenti.
+
+- **Reattività al cambio lingua**: Cambio la lingua usando il controllo dell'app stessa e cronometro quanto tempo passa finché la pagina non è chiaramente cambiata, quello che un visitatore noterebbe.
+
+- **Lavoro di rendering dopo un cambio di lingua**: Un follow-up più preciso: quanto sforzo ha impiegato l'interfaccia per ridisegnarsi per la nuova lingua una volta avviato il cambio. Utile quando il tempo "percepito" e il costo del framework divergono.
+
+- **Tempo di caricamento iniziale della pagina**: Dalla navigazione fino a quando il browser considera la pagina completamente caricata per gli scenari testati. Utile per confrontare gli avvii a freddo.
+
+- **Tempo di idratazione (Hydration)**: Il tempo che il client impiega per trasformare l'HTML del server in un'interfaccia interattiva. Un trattino nelle tabelle significa che quella implementazione non ha fornito una cifra di idratazione affidabile in questo benchmark.
+
+## Risultati in dettaglio
+
+### 1 — Soluzioni da evitare
+
+> Nessuna soluzione chiara da evitare nell'ecosistema Vue.
+
+### 2 — Soluzioni accettabili
+
+**(vue-i18n)** (`vue-i18n@11.4.0`):
+
+- **vue-i18n** è senza dubbio la libreria i18n più utilizzata per Vue, ha molte funzionalità e un ecosistema immenso. Ma sotto il cofano la soluzione è piuttosto pesante. Anche se vue-i18n integra il caricamento pigro dei messaggi, manca di una funzione di scoping. Nel caso di una classica app Vue SPA non ci sono problemi, ma per un'app Nuxt, utilizzando @nuxt/i18n, ciò porta a includere i messaggi di tutte le pagine in una sola. Per una grande app Nuxt con più di 10 pagine, può diventare davvero problematico.
+
+Il pacchetto è molto pesante (~24.3kb, circa 9 volte `vue-intlayer`).
+
+**(fluent-vue)** (`fluent-vue@0.5.0`):
+
+- **fluent-vue** offre un tentativo di innovazione attraverso il formato .ftl. L'organizzazione dei messaggi è ottima, più facile per iniziare. Ma in pratica, la mancanza di type-safety aumenta il rischio di errore e può diventare rapidamente dispendioso in termini di tempo per il debug. Inoltre, questa soluzione carica i messaggi tramite un plugin vite che forza il caricamento di tutto il contenuto in tutte le lingue in ogni pagina. Inoltre, è una soluzione estremamente pesante (~92.7kb, circa 34 volte `vue-intlayer`).
+
+### 3 — Raccomandazioni
+
+**(Intlayer)** (`vue-intlayer@8.7.12`):
+
+Non giudicherò personalmente `vue-intlayer` per motivi di obiettività, essendo la mia soluzione.