@intlayer/docs 8.12.5-canary.0 → 9.0.0-canary.10

package/docs/it/benchmark/solid.md

@@ -118,6 +118,28 @@ Abbiamo confrontato **quattro strategie di caricamento**:
 - **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.
 
+### Ciò che ho misurato:
+
+Ho eseguito la stessa app multilingue in un vero browser per ogni stack, quindi ho annotato ciò che è effettivamente apparso sulla rete e quanto tempo ha impiegato. Le dimensioni sono riportate **dopo la normale compressione web**, perché è più vicino a ciò che le persone scaricano rispetto ai conteggi grezzi delle sorgenti.
+
+- **Internationalization library size**: Dopo il bundling, tree-shaking e minification, la dimensione della libreria i18n è la dimensione dei provider + codice hooks/primitives in un componente vuoto. Non include il caricamento dei file di traduzione. Risponde a quanto è costosa la libreria prima che il tuo contenuto entri in gioco.
+
+- **JavaScript per page**: Per ogni rotta di benchmark, quanti script il browser scarica per quella visita, mediati tra le pagine della suite (e tra le lingue dove il rapporto le raggruppa). Le pagine pesanti sono pagine lente.
+
+- **Leakage from other locales**: È il contenuto della stessa pagina ma in un'altra lingua che verrebbe caricato per errore nella pagina sottoposta a audit. Questo contenuto è inutile e dovrebbe essere evitato. (ad es. contenuto della pagina `/fr/about` nel bundle della pagina `/en/about`)
+
+- **Leakage from other routes**: La stessa idea per **altri schermi** nell'app: se la loro copia si carica insieme quando hai aperto solo una pagina. (ad es. contenuto della pagina `/en/about` nel bundle della pagina `/en/contact`). Un punteggio elevato suggerisce uno splitting debole o bundle troppo ampi.
+
+- **Average component bundle size**: I pezzi UI comuni sono misurati **uno alla volta** invece di nascondersi in un numero gigante dell'app. Mostra se l'internazionalizzazione aumenta silenziosamente i componenti quotidiani. Ad esempio, se il tuo componente viene ripetuto, caricherà tutti i dati dalla memoria. Allegare un giant JSON a qualsiasi componente è come collegare un grande archivio di dati non utilizzati che rallenterà le prestazioni dei tuoi componenti.
+
+- **Language switch responsiveness**: Cambio la lingua usando il controllo dell'app e cronometro quanto tempo ci vuole prima che la pagina sia chiaramente cambiata, quello che un visitatore noterebbe, non un micro-step di laboratorio.
+
+- **Rendering work after a language change**: Un follow-up più mirato: quanto sforzo ha richiesto all'interfaccia di ridipingere per la nuova lingua una volta che lo switch è in volo. Utile quando il tempo "percepito" e il costo del framework divergono.
+
+- **Initial page load time**: Dalla navigazione al browser che considera la pagina completamente caricata per gli scenari che ho testato. Buono per confrontare i cold start.
+
+- **Hydration time**: Quando l'app lo espone, quanto tempo il client spende a trasformare l'HTML del server in qualcosa su cui puoi effettivamente fare clic. Un trattino nelle tabelle significa che quella implementazione non ha fornito una figura di hydration affidabile in questo benchmark.
+
 ## Stelle di GitHub
 
 Le stelle di GitHub sono un forte indicatore della popolarità di un progetto, della fiducia della comunità e della pertinenza a lungo termine. Sebbene non siano una misura diretta della qualità tecnica, riflettono quanti sviluppatori trovano il progetto utile, ne seguono i progressi e sono propensi ad adottarlo. Per stimare il valore di un progetto, le stelle aiutano a confrontare la trazione tra le alternative e forniscono approfondimenti sulla crescita dell'ecosistema.

package/docs/it/benchmark/svelte.md

@@ -116,6 +116,28 @@ Abbiamo confrontato **quattro strategie di caricamento**:
 - **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 vero browser per ogni stack, quindi ho annotato cosa è effettivamente apparso sulla rete e quanto tempo ci è voluto. Le dimensioni sono riportate **dopo la normale compressione web**, perché è più vicino a quello che le persone scaricano rispetto ai conteggi del codice sorgente grezzo.
+
+- **Dimensione della libreria di internazionalizzazione**: Dopo il bundling, il tree-shaking e la minificazione, la dimensione della libreria i18n è la dimensione del codice dei provider + store in un componente vuoto. Non include il caricamento dei file di traduzione. Risponde a quanto è costosa la libreria prima che il tuo contenuto entri in gioco.
+
+- **JavaScript per pagina**: Per ogni route di benchmark, quanto script il browser estrae per quella visita, in media nelle pagine della suite (e tra i locale dove il rapporto li raggruppa). Le pagine pesanti sono pagine lente.
+
+- **Perdita da altri locale**: È il contenuto della stessa pagina ma in un'altra lingua che verrebbe caricato per errore nella pagina controllata. Questo contenuto è non necessario e dovrebbe essere evitato. (ad es. il contenuto della pagina `/fr/about` nel bundle della pagina `/en/about`)
+
+- **Perdita da altri percorsi**: La stessa idea per **altri schermi** nell'app: se il loro contenuto viene trasportato quando hai aperto solo una pagina. (ad es. il contenuto della pagina `/en/about` nel bundle della pagina `/en/contact`). Un punteggio alto suggerisce uno splitting debole o bundle troppo ampi.
+
+- **Dimensione media del bundle dei componenti**: I pezzi comuni dell'interfaccia utente vengono misurati **uno alla volta** invece di nascondersi in un gigantesco numero di app. Mostra se l'internazionalizzazione gonfia silenziosamente i componenti quotidiani. Ad esempio, se il tuo componente esegue il rerender, caricherà tutti quei dati dalla memoria. Allegare un JSON gigante a qualsiasi componente è come collegare un grande negozio di dati inutilizzati che rallenterà le prestazioni dei tuoi componenti.
+
+- **Reattività del cambio di lingua**: Cambio la lingua usando il controllo dell'app e cronometro quanto tempo impiega fino a quando la pagina non si è chiaramente cambiata, quello che un visitatore noterebbe, non un micro-step di laboratorio.
+
+- **Lavoro di rendering dopo un cambio di lingua**: Un seguito più ristretto: quanta fatica l'interfaccia ha impiegato per dipingere di nuovo per la nuova lingua una volta che il cambio è in corso. Utile quando il tempo "percepito" e il costo del framework divergono.
+
+- **Tempo di caricamento della pagina iniziale**: Dalla navigazione al browser considerando la pagina completamente caricata per gli scenari che ho testato. Buono per confrontare i cold start.
+
+- **Tempo di idratazione**: Quando l'app lo espone, quanto tempo il client impiega a trasformare l'HTML del server in qualcosa che puoi effettivamente cliccare. Un trattino nelle tabelle significa che quella implementazione non ha fornito una figura di idratazione affidabile in questo benchmark.
+
 ## Stelle di GitHub
 
 Le stelle di GitHub sono un forte indicatore della popolarità di un progetto, della fiducia della comunità e della pertinenza a lungo termine. Sebbene non siano una misura diretta della qualità tecnica, riflettono quanti sviluppatori trovano il progetto utile, ne seguono i progressi e sono propensi ad adottarlo. Per stimare il valore di un progetto, le stelle aiutano a confrontare la trazione tra le alternative e forniscono approfondimenti sulla crescita dell'ecosistema.

package/docs/it/benchmark/tanstack.md

@@ -124,6 +124,28 @@ Abbiamo confrontato **quattro strategie di caricamento**:
 - **Scoped static**: Mantiene il codice organizzato (separazione logica) senza requisiti di rete complessi.
 - **Scoped dynamic**: Il miglior approccio per il _code splitting_ e le prestazioni. Riduce al minimo 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 vero browser per ogni stack, quindi ho annotato cosa è effettivamente apparso sulla rete e quanto tempo ha impiegato. Le dimensioni sono riportate **dopo la normale compressione web**, perché è più vicino a quello che le persone scaricano rispetto ai conteggi del codice sorgente grezzo.
+
+- **Dimensione della libreria di internazionalizzazione**: Dopo il bundling, tree-shaking e minification, la dimensione della libreria i18n è la dimensione dei provider (ad es. `NextIntlClientProvider`) + il codice degli hook (ad es. `useTranslations`) in un componente vuoto. Non include il caricamento dei file di traduzione. Risponde a quanto è costosa la libreria prima che il tuo contenuto entri in gioco.
+
+- **JavaScript per pagina**: Per ogni route di benchmark, quanto script il browser scarica in quella visita, mediato tra le pagine della suite (e tra le lingue dove il rapporto le raggruppa). Le pagine pesanti sono pagine lente.
+
+- **Perdita da altre lingue**: È il contenuto della stessa pagina ma in un'altra lingua che verrebbe caricato per errore nella pagina controllata. Questo contenuto è non necessario e dovrebbe essere evitato. (ad es. il contenuto della pagina `/fr/about` nel bundle della pagina `/en/about`)
+
+- **Perdita da altre route**: La stessa idea per **altri schermi** nell'app: se la loro copia viene trascinata quando apri solo una pagina. (ad es. il contenuto della pagina `/en/about` nel bundle della pagina `/en/contact`). Un punteggio alto suggerisce uno splitting debole o bundle troppo ampi.
+
+- **Dimensione media del bundle del componente**: I pezzi comuni dell'interfaccia utente vengono misurati **uno alla volta** invece di nascondersi all'interno di un numero gigante dell'app. Mostra se l'internazionalizzazione gonfia silenziosamente i componenti di tutti i giorni. Ad esempio, se il tuo componente si rirenderizza, caricherà tutti questi dati dalla memoria. Allegare un JSON gigante a qualsiasi componente è come collegare un grande archivio di dati inutilizzati che rallenterà le prestazioni dei tuoi componenti.
+
+- **Reattività del cambio di lingua**: Cambio la lingua usando il controllo dell'app e misuro quanto tempo impiega fino a quando la pagina non è chiaramente cambiata, quello che un visitatore noterebbe, non un micro-step di laboratorio.
+
+- **Lavoro di rendering dopo un cambio di lingua**: Un follow-up più ristretto: quanto sforzo ha impiegato l'interfaccia per ridisegnare la nuova lingua una volta che lo switch è in volo. Utile quando il tempo "percepito" e il costo del framework divergono.
+
+- **Tempo di caricamento iniziale della pagina**: Dalla navigazione al browser che considera la pagina completamente caricata per gli scenari che ho testato. Buono per confrontare i cold start.
+
+- **Tempo di idratazione**: Quando l'app lo espone, quanto tempo il client spende a trasformare l'HTML del server in qualcosa su cui puoi effettivamente fare clic. Un trattino nelle tabelle significa che l'implementazione non ha fornito una cifra di idratazione affidabile in questo benchmark.
+
 ## Stelle di GitHub
 
 Le stelle di GitHub sono un forte indicatore della popolarità di un progetto, della fiducia della comunità e della pertinenza a lungo termine. Sebbene non siano una misura diretta della qualità tecnica, riflettono quanti sviluppatori trovano il progetto utile, ne seguono i progressi e sono propensi ad adottarlo. Per stimare il valore di un progetto, le stelle aiutano a confrontare la trazione tra le alternative e forniscono approfondimenti sulla crescita dell'ecosistema.

package/docs/it/cli/ci.md

@@ -140,6 +140,28 @@ steps:
     run: npx intlayer ci fill
 ```
 
+## GitHub Actions scaffoldati
+
+Quando esegui `intlayer init`, Intlayer rileva il tuo package manager (npm, yarn, pnpm, o bun) e scaffolda due workflow GitHub Actions in `.github/workflows/`, con comandi che corrispondono a quel package manager:
+
+- **`intlayer-fill.yml`** — Su ogni pull request, costruisce i dizionari ed esegue `intlayer fill --git-diff --mode complete` per generare le traduzioni mancanti per i dizionari modificati, quindi esegue il commit del risultato nel branch della PR.
+- **`intlayer-test.yml`** — Su ogni pull request, costruisce i dizionari ed esegue `intlayer test`, fallendo il check quando le locale richieste hanno traduzioni mancanti.
+
+I file di workflow esistenti non vengono mai sovrascritti. Per saltare completamente lo scaffolding, esegui:
+
+```bash
+npx intlayer init --no-github-actions
+```
+
+### Fornire accesso AI al workflow di fill
+
+Il file `intlayer-fill.yml` scaffoldato richiede accesso AI. Sono disponibili due opzioni (configurate nel blocco `env` del workflow):
+
+1. **La tua chiave di provider AI** — Aggiungi un secret `AI_API_KEY` nelle impostazioni del repository (Settings → Secrets and variables → Actions). Il workflow la inoltra tramite `--provider`, `--model`, e `--api-key`.
+2. **Chiavi di accesso Intlayer CMS** — Aggiungi i secret `INTLAYER_CLIENT_ID` e `INTLAYER_CLIENT_SECRET` e collegali alla sezione `editor` del tuo `intlayer.config`. Le chiavi di accesso CMS concedono accesso AI tramite il backend di Intlayer.
+
+Il workflow `intlayer-test.yml` non richiede alcun accesso AI.
+
 ## Gestione degli errori
 
 - Se `INTLAYER_PROJECT_CREDENTIALS` non è impostata, il comando terminerà con un errore.

package/docs/it/cli/doc-review.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-06-17
 title: Revisione Documento
 description: Scopri come revisionare i file di documentazione per qualità, coerenza e completezza tra diverse localizzazioni.
 keywords:
@@ -15,6 +15,10 @@ slugs:
   - concept
   - cli
   - doc-review
+history:
+  - version: 9.0.0
+    date: 2026-06-17
+    changes: "Aggiunta opzione --log"
 author: aymericzip
 ---
 
@@ -55,8 +59,110 @@ Per la maggior parte dei casi d'uso,
 
 ## Argomenti:
 
-Il comando `doc review` accetta gli stessi argomenti di `doc translate`, permettendoti di revisionare file di documentazione specifici e applicare controlli di qualità.
+**Opzioni lista file:**
 
-Se hai attivato una delle opzioni git, il comando revisionerà solo la parte dei file che viene modificata. Lo script processerà il file suddividendolo in chunk e revisionerà ogni chunk. Se non ci sono modifiche nel chunk, lo script lo salterà per velocizzare il processo di revisione e limitare il costo dell'API del provider AI.
+- **`--doc-pattern [docPattern...]`**: Pattern glob per selezionare i file di documentazione da revisionare.
 
-Per un elenco completo degli argomenti, consulta la documentazione del comando [Translate Document](https://github.com/aymericzip/intlayer/blob/main/docs/docs/it/cli/doc-translate.md).
+  > Esempio: `npx intlayer doc review --doc-pattern "docs/**/*.md" "src/**/*.mdx"`
+
+- **`--excluded-glob-pattern [excludedGlobPattern...]`**: Pattern glob da escludere dalla revisione.
+
+  > Esempio: `npx intlayer doc review --excluded-glob-pattern "docs/internal/**"`
+
+- **`--skip-if-modified-before [skipIfModifiedBefore]`**: Salta il file se è stato modificato prima del tempo indicato.
+  - Può essere un tempo assoluto como "2025-12-05" (stringa o Date)
+  - Può essere un tempo relativo in ms `1 * 60 * 60 * 1000` (1 ora)
+  - Questa opzione controlla il tempo di aggiornamento del file usando il metodo `fs.stat`. Quindi potrebbe essere influenzata da Git o altri strumenti che modificano il file.
+
+  > Esempio: `npx intlayer doc review --skip-if-modified-before "2025-12-05"`
+
+- **`--skip-if-modified-after [skipIfModifiedAfter]`**: Salta il file se è stato modificato entro il tempo indicato.
+  - Può essere un tempo assoluto como "2025-12-05" (stringa o Date)
+  - Può essere un tempo relativo in ms `1 * 60 * 60 * 1000` (1 ora)
+  - Cette opzione controlla il tempo di aggiornamento del file usando il metodo `fs.stat`. Quindi potrebbe essere influenzata da Git o altri strumenti che modificano il file.
+
+  > Esempio: `npx intlayer doc review --skip-if-modified-after "2025-12-05"`
+
+- **`--skip-if-exists`**: Salta il file se esiste già.
+
+  > Esempio: `npx intlayer doc review --skip-if-exists`
+
+**Opzioni di modalità di revisione:**
+
+- **`--log`**: Modalità solo log. Non traduce con l'IA; registra invece i blocchi che richiedono attenzione (con numeri di riga e contenuto) per i locali base e target, per aiutare un altro agente a generare le traduzioni.
+
+  > Esempio: `npx intlayer doc review --log`
+
+**Opzioni di output delle voci:**
+
+- **`--locales [locales...]`**: Locales di destinazione per revisionare la documentazione.
+
+  > Esempio: `npx intlayer doc review --locales fr es de`
+
+- **`--base-locale [baseLocale]`**: Locale sorgente (documento base) con cui confrontare.
+
+  > Esempio: `npx intlayer doc review --base-locale en`
+
+**Opzioni di elaborazione dei file:**
+
+- **`--nb-simultaneous-file-processed [nbSimultaneousFileProcessed]`**: Numero di file da processare simultaneamente per la revisione.
+
+  > Esempio: `npx intlayer doc review --nb-simultaneous-file-processed 5`
+
+**Opzioni AI:**
+
+- **`--model [model]`**: Il modello AI da utilizzare per la revisione (es. `gpt-3.5-turbo`).
+- **`--provider [provider]`**: Il provider AI da utilizzare per la revisione.
+- **`--temperature [temperature]`**: Impostazione della temperatura per il modello AI.
+- **`--api-key [apiKey]`**: Fornisci la tua chiave API per il servizio AI.
+- **`--application-context [applicationContext]`**: Fornisci un contesto aggiuntivo per la revisione AI.
+- **`--data-serialization [dataSerialization]`**: Il formato di serializzazione dei dati da utilizzare per le funzionalità AI di Intlayer. Opzioni: `json` (standard, affidabile), `toon` (meno token, meno coerente).
+- **`--custom-prompt [prompt]`**: Personalizza il prompt base utilizzato per la revisione. (Nota: per la maggior parte dei casi d'uso, si consiglia invece l'opzione `--custom-instructions` in quanto offre un controllo migliore.)
+
+  > Esempio: `npx intlayer doc review --model deepseek-chat --provider deepseek --temperature 0.5 --api-key sk-1234567890 --application-context "La mia applicazione è un negozio di gatti"`
+
+**Opzioni variabili d'ambiente:**
+
+- **`--env`**: Specifica l'ambiente (es. `development`, `production`).
+- **`--env-file [envFile]`**: Fornisce un file ambiente personalizzato da cui caricare le variabili.
+- **`--base-dir`**: Specifica la directory base per il progetto.
+- **`--no-cache`**: Disabilita la cache.
+
+  > Esempio: `npx intlayer doc review --base-dir ./docs --env-file .env.production.local`
+
+**Opzioni di log:**
+
+- **`--verbose`**: Abilita il logging dettagliato per il debugging. (impostazione predefinita a true usando la CLI)
+
+  > Esempio: `npx intlayer doc review --verbose`
+
+**Opzioni istruzioni personalizzate:**
+
+- **`--custom-instructions [customInstructions]`**: Istruzioni personalizzate aggiunte al prompt. Utile per applicare regole specifiche riguardo al formato, alla traduzione degli URL, ecc.
+
+  > Esempio: `npx intlayer doc review --custom-instructions "Evita di tradurre gli URL e mantieni il formato markdown"`
+
+  > Esempio: `npx intlayer doc review --custom-instructions "$(cat ./instructions.md)"`
+
+**Opzioni Git:**
+
+- **`--git-diff`**: Esegui solo sui file che includono modifiche dalla base (predefinita `origin/main`) al branch corrente (predefinito: `HEAD`).
+- **`--git-diff-base`**: Specifica il riferimento base per il git diff (predefinito `origin/main`).
+- **`--git-diff-current`**: Specifica il riferimento corrente per il git diff (predefinito `HEAD`).
+- **`--uncommitted`**: Includi le modifiche non committate.
+- **`--unpushed`**: Includi le modifiche non pushate.
+- **`--untracked`**: Includi i file non tracciati.
+
+  > Esempio: `npx intlayer doc review --git-diff --git-diff-base origin/main --git-diff-current HEAD`
+
+  > Esempio: `npx intlayer doc review --uncommitted --unpushed --untracked`
+
+> Nota che il percorso del file di output sarà determinato sostituendo i seguenti pattern:
+>
+> - `/{{baseLocale}}/` con `/{{locale}}/` (Unix)
+> - `\{{baseLocale}}\` con `\{{locale}}\` (Windows)
+> - `_{{baseLocale}}.` con `_{{locale}}.`
+> - `{{baseLocale}}_` con `{{locale}}_`
+> - `.{{baseLocaleName}}.` con `.{{localeName}}.`
+>
+> Se il pattern non viene trovato, il file di output aggiungerà `.{{locale}}` all'estensione del file. `./my/file.md` sarà revisionato e aggiornato in `./my/file.fr.md` per la localizzazione francese.

package/docs/it/cli/fill.md

@@ -47,6 +47,14 @@ Punti chiave:
 - Preserva le traduzioni esistenti non sovrascrivendole.
 - Elabora file, parti e locali in parallelo utilizzando un sistema di code per aumentare la velocità.
 
+## Punti Chiave:
+
+- Divide i file JSON di grandi dimensioni in chunk per rispettare i limiti della finestra di contesto del modello di IA.
+- Riprova la traduzione se il formato dell'output è errato.
+- Incorpora il contesto specifico dell'applicazione e del file per migliorare l'accuratezza della traduzione.
+- Preserva le traduzioni esistenti senza sovrascriverle.
+- Elabora file, chunk e locale in parallelo utilizzando un sistema di queue per aumentare la velocità.
+
 ## Alias:
 
 - `npx intlayer dictionaries fill`

package/docs/it/cli/index.md

@@ -17,7 +17,7 @@ slugs:
   - concept
   - cli
 history:
-  - version: 8.13.0
+  - version: 9.0.0
     date: 2026-06-11
     changes: "Aggiunto comando scan"
   - version: 8.6.4

package/docs/it/cli/scan.md

@@ -18,7 +18,7 @@ slugs:
   - cli
   - scan
 history:
-  - version: 8.13.0
+  - version: 9.0.0
     date: 2026-06-11
     changes: "Aggiunto comando scan"
 author: aymericzip

package/docs/it/compat/i18n-js.md

@@ -0,0 +1,44 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migrare da i18n-js a Intlayer"
+description: "Scopri come migrare la tua applicazione da i18n-js a Intlayer utilizzando l'adattatore di compatibilità."
+keywords:
+  - i18n-js
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - i18n-js
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Migrare da i18n-js a Intlayer
+
+La transizione dalla libreria `i18n-js` a Intlayer è una migrazione altamente ottimizzata progettata per trasferire grandi configurazioni di traduzioni nel sistema di risoluzione dei file strutturato di Intlayer.
+
+## Cosa fare
+
+Esegui il seguente comando di configurazione nel tuo repository:
+
+```bash
+npx intlayer init
+```
+
+Con `intlayer.config.ts` preparato, puoi aggiungere l'alias di Intlayer alla configurazione del tuo bundler in modo che qualsiasi importazione di `i18n-js` abbia come destinazione il package di compatibilità `@intlayer/i18n-js`.
+
+## Cosa fa sotto il cofano
+
+`i18n-js` accede ai namespace attraverso espressioni come `i18n.t('scope.key', {name})` insieme ai fallback locale e alle mappature plurali specifiche.
+
+Sotto il cofano:
+
+- **Interpolation:** L'adapter di compatibilità analizza facilmente le mappature `%{name}` nel valore del dizionario runtime di destinazione.
+- **Pluralization:** Sostituisce le sottochiavi `one/other` e le mappa rispetto ai potenti meccanismi plurali sottostanti di Intlayer (`Intl.PluralRules`), astraendo le mappature manuali.
+- **Locales:** Invece di caricare payload linguistici monolitici al bootstrap, i dizionari vengono serviti in modo ottimale in base alla configurazione del contesto corrente tramite la configurazione nativa di Intlayer.

package/docs/it/compat/i18next.md

@@ -0,0 +1,59 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migrare da i18next a Intlayer"
+description: "Scopri come migrare la tua applicazione Vanilla JS/TS da i18next a Intlayer utilizzando l'adattatore di compatibilità."
+keywords:
+  - i18next
+  - vanilla
+  - javascript
+  - typescript
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - i18next
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Migrazione da i18next a Intlayer
+
+Per un tutorial dettagliato passo-passo, consulta la nostra completa [Guida alla migrazione da i18next](../migration_from_i18next_to_intlayer.md).
+
+Intlayer replica perfettamente le caratteristiche runtime core di `i18next`. Utilizzando il package compat, le tue applicazioni Vanilla o i moduli interni possono continuare a sfruttare la sintassi familiare.
+
+## Cosa fare
+
+Per iniziare, inizializza Intlayer nel tuo progetto:
+
+```bash
+npx intlayer init
+```
+
+Se stai utilizzando Vite, includi il plugin Intlayer per instradare gli import a `@intlayer/i18next`:
+
+```typescript fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import { i18nextVitePlugin } from "@intlayer/i18next/plugin";
+
+export default defineConfig({
+  plugins: [i18nextVitePlugin()],
+});
+```
+
+## Cosa fa sotto il cofano
+
+Il `i18nextVitePlugin` reindirizza gli import `i18next` a `@intlayer/i18next`, evitando l'aumento del bundle dalle inclusioni dei file JSON.
+
+Sotto il cofano:
+
+- **Configurazione dell'istanza:** `createInstance` analizza correttamente e applica i fallback degli namespace sfruttando la pipeline di compilazione di Intlayer per il recupero del dizionario.
+- **Interpolazione:** Supporto nativo per le sostituzioni `{{name}}` e l'annidamento ricorsivo di `$t(key)`.
+- **Contesto e plurali:** Identifica e risolve i formati di suffisso come `key_male` e `key_one`/`key_other` valutandoli rispetto allo standard `Intl.PluralRules`.
+- **Oggetti di ritorno:** La modalità `returnObjects: true` estrae in sicurezza gli alberi dai dizionari di Intlayer.

package/docs/it/compat/index.md

@@ -0,0 +1,51 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Intlayer Compat Adapters"
+description: "Migra la tua soluzione i18n esistente a Intlayer senza attriti utilizzando compat adapters."
+keywords:
+  - compat
+  - migration
+  - internationalization
+  - i18n
+  - Intlayer
+slugs:
+  - doc
+  - compatibility
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Adattatori di compatibilità Intlayer
+
+La migrazione di un'applicazione di grandi dimensioni a una nuova libreria di internazionalizzazione può essere impegnativa. Per facilitare questa transizione, Intlayer fornisce **adattatori di compatibilità** per le librerie i18n più popolari dell'ecosistema.
+
+Questi pacchetti adattatore espongono la **stessa API pubblica** delle tue librerie i18n esistenti, ma delegano tutto il lavoro di traduzione a Intlayer a runtime.
+
+## Come funziona
+
+Quando usi un compat adapter, non hai bisogno di riscrivere gli import della tua applicazione o cambiare come utilizzi i tuoi translation hooks e componenti. Invece, i plugin bundler di Intlayer eseguono automaticamente l'alias dei tuoi import esistenti ai package compat di Intlayer.
+
+Ad esempio, uno sviluppatore sostituisce `import { useTranslation } from 'react-i18next'` con `import { useTranslation } from '@intlayer/react-i18next'` (fatto automaticamente dal plugin bundler), e l'app continua a funzionare con le traduzioni ora servite dai dizionari di Intlayer. Le chiavi sono anche tipizzate rispetto ai tuoi dizionari di Intlayer!
+
+## Adattatori Compat Disponibili
+
+Scegli la tua libreria esistente di seguito per vedere come eseguire la migrazione senza problemi:
+
+- [Vue I18n](./vue-i18n.md)
+- [Transloco](./transloco.md)
+- [React Intl](./react-intl.md)
+- [Svelte I18n](./svelte-i18n.md)
+- [React i18next](./react-i18next.md)
+- [Polyglot.js](./polyglot.md)
+- [NuxtJS I18n](./nuxtjs-i18n.md)
+- [NGX Translate](./ngx-translate.md)
+- [Next Translate](./next-translate.md)
+- [Next Intl](./next-intl.md)
+- [Next i18next](./next-i18next.md)
+- [i18next](./i18next.md)
+- [Lingui](./lingui.md)
+- [I18n-js](./i18n-js.md)

package/docs/it/compat/lingui.md

@@ -0,0 +1,44 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migrare da Lingui a Intlayer"
+description: "Scopri come migrare la tua applicazione da Lingui a Intlayer utilizzando l'adattatore di compatibilità."
+keywords:
+  - lingui
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - lingui
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Migrazione da Lingui a Intlayer
+
+Se il tuo progetto attualmente si basa sulla compilazione basata su macro di Lingui, il passaggio a Intlayer ti consente di mantenere i tuoi potenti workflow macro supportandoli nativamente con la strategia di compilazione JSON di Intlayer.
+
+## Cosa fare
+
+Per iniziare, inizializza Intlayer nel tuo progetto:
+
+```bash
+npx intlayer init
+```
+
+Questo crea il tuo `intlayer.config.ts`. Assicurati di mantenere `@lingui/babel-plugin-lingui-macro` / `@lingui/swc-plugin` nel tuo build step per eseguire _prima_ del compilatore Intlayer. Quindi, utilizza l'alias del plugin bundler per instradare `@lingui/core` e `@lingui/react` a `@intlayer/lingui`.
+
+## Cosa fa sotto il cofano
+
+Lingui utilizza macro (come `` t`Hello ${name}` `` e `<Trans>`) che vengono compilate in chiamate runtime come `i18n._(id, values)`.
+
+Sotto il cofano:
+
+- **Macro:** Si compilano esattamente come prima, garantendo nessuna interruzione nella sintassi del tuo codice sorgente.
+- **Traduzione runtime:** L'alias `i18n._()` utilizza i dizionari di Intlayer. Sia gli ID esplicitamente denominati che gli ID con hash sono completamente mappati utilizzando i plugin di sincronizzazione `.po` di Intlayer per aggregare e rimuovere le chiavi in modo sicuro.
+- **Funzionalità ICU:** Il supporto per pluralizzazione, selezione e varianti ICU rimane robusto grazie al parser ICU unificato di Intlayer, garantendo output di rendering identici.

package/docs/it/compat/next-i18next.md

@@ -0,0 +1,57 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migrare da next-i18next a Intlayer"
+description: "Scopri come migrare la tua applicazione Next.js da next-i18next a Intlayer utilizzando l'adapter di compatibilità."
+keywords:
+  - next-i18next
+  - nextjs
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - next-i18next
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Migra da next-i18next a Intlayer
+
+Per un tutorial completo e dettagliato passo dopo passo, consulta la nostra [Guida alla migrazione da next-i18next](../migration_from_next-i18next_to_intlayer.md).
+
+Intlayer gestisce tutte le implementazioni di Next.js Pages Router e App Router in modo trasparente. Utilizzando l'adapter puoi migrare la tua implementazione `next-i18next` senza riscrivere il codice.
+
+## Cosa fare
+
+Per iniziare, esegui:
+
+```bash
+npx intlayer init
+```
+
+Questo crea il file di configurazione Intlayer necessario. Per integrare Intlayer dietro le quinte, aggiorna il tuo `next.config.ts`:
+
+```typescript fileName="next.config.ts"
+import type { NextConfig } from "next";
+import { createNextI18nPlugin } from "@intlayer/next-i18next/plugin";
+
+const withIntlayer = createNextI18nPlugin();
+
+const nextConfig: NextConfig = {};
+
+export default withIntlayer(nextConfig);
+```
+
+## Come funziona internamente
+
+Il `createNextI18nPlugin` combina il comportamento nativo di Next.js insieme al plugin core `next-intlayer`, iniettando tutti gli alias Webpack/Turbopack richiesti per `next-i18next`, `react-i18next` e `i18next`.
+
+Internamente:
+
+- **`serverSideTranslations` & `appWithTranslation`:** Ora funzionano come wrapper per i loader interni di Intlayer, evitando l'iniezione di grandi JSON statici.
+- **Client hooks:** Delega immediatamente a `@intlayer/react-i18next` mantenendo tutti i formati, i plurali e le funzionalità degli spazi dei nomi annidati.

package/docs/it/compat/next-intl.md

@@ -0,0 +1,59 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migrare da next-intl a Intlayer"
+description: "Scopri come migrare la tua applicazione Next.js da next-intl a Intlayer utilizzando l'adapter di compatibilità."
+keywords:
+  - next-intl
+  - nextjs
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - next-intl
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Migrare da next-intl a Intlayer
+
+Per un tutorial completo e dettagliato passo dopo passo, consulta la nostra [Guida alla Migrazione da next-intl](../migration_from_next-intl_to_intlayer.md).
+
+La migrazione da `next-intl` a Intlayer ti consente di mantenere il routing dell'applicazione e la sintassi completamente intatti.
+
+## Cosa fare
+
+Esegui il seguente comando nel tuo repository:
+
+```bash
+npx intlayer init
+```
+
+Questo creerà un file `intlayer.config.ts`. Nel tuo `next.config.ts`, utilizza il wrapper del plugin per iniettare facilmente gli alias `next-intl` verso `@intlayer/next-intl`.
+
+```typescript fileName="next.config.ts"
+import type { NextConfig } from "next";
+import { createNextIntlPlugin } from "@intlayer/next-intl/plugin";
+
+const withIntlayer = createNextIntlPlugin();
+
+const nextConfig: NextConfig = {};
+
+export default withIntlayer(nextConfig);
+```
+
+## Cosa fa sotto il cofano
+
+Il bundler wrapper sostituisce le traduzioni, ma **lascia intatte le funzionalità di `next-intl/navigation`** (ad es. `Link`, `redirect`, `usePathname`).
+
+Sotto il cofano:
+
+- **ICU runtime:** I plurali (`=0`, `one`, `other`), select/selectordinal, gli argomenti `#` e gli argomenti formattati (`{ts, date, long}`) funzionano correttamente utilizzando il resolver condiviso `resolveMessage(..., 'icu')`.
+- **`useTranslations()` & `getTranslations()`:** Le chiamate di scope bare estraggono il primo segmento di chiave come identificatore corretto del dizionario. Gli spazi dei nomi annidati si dividono elegantemente in percorsi di dizionario e prefissi.
+- **Rich formatting:** Sia `t.rich()` che `t.markup()` sono completamente implementati in modo nativo, convertendo i nodi simili a HTML in chunk React renderizzati.
+- **`useFormatter`:** `relativeTime`, `list`, `dateTimeRange` e i formati denominati dalla configurazione si collegano ai formatter `Intl` nativi principali.