@intlayer/docs 9.0.0-canary.3 → 9.0.0-canary.5

package/docs/id/packages/vue-intlayer/usePathname.md

@@ -0,0 +1,109 @@
+---
+createdAt: 2026-06-22
+updatedAt: 2026-06-22
+title: Dokumentasi Fungsi usePathname | vue-intlayer
+description: Pelajari cara menggunakan fungsi usePathname dari paket vue-intlayer
+keywords:
+  - usePathname
+  - pathname
+  - locale
+  - Intlayer
+  - Internasionalisasi
+  - Dokumentasi
+  - Vue
+  - JavaScript
+slugs:
+  - doc
+  - packages
+  - vue-intlayer
+  - usePathname
+history:
+  - version: 10.0.0
+    date: 2026-06-23
+    changes: "Tambahkan utilitas usePathname"
+  - version: 8.2.0
+    date: 2026-06-22
+    changes: "Inisialisasi riwayat"
+author: aymericzip
+---
+
+# Integrasi Vue: Dokumentasi `usePathname`
+
+Fungsi `usePathname` mengembalikan pathname browser saat ini dengan segmen locale yang dihapus, dalam bentuk Vue `ComputedRef<string>`. Ini berguna untuk membangun navigasi yang sadar-locale — misalnya, untuk menentukan item navigasi mana yang sedang aktif — tanpa harus menghapus awalan locale secara manual.
+
+## Mengimpor `usePathname` di Vue
+
+```typescript
+import { usePathname } from "vue-intlayer";
+```
+
+## Ikhtisar
+
+`usePathname` membuat referensi terkomputasi (computed ref) Vue yang membaca `window.location.pathname`, menghapus awalan locale melalui `getPathWithoutLocale`, dan memperbarui nilainya setiap kali browser memicu peristiwa `popstate` (navigasi mundur/maju). Nilai ini dapat digunakan langsung di dalam template Vue atau fungsi setup Anda.
+
+## Penggunaan
+
+```vue fileName="src/components/NavItem.vue"
+<script setup lang="ts">
+import { usePathname } from "vue-intlayer";
+
+const props = defineProps<{
+  href: string;
+  label: string;
+}>();
+
+const pathname = usePathname();
+</script>
+
+<template>
+  <a :href="href" :aria-current="pathname === href ? 'page' : undefined">
+    {{ label }}
+  </a>
+</template>
+```
+
+## Nilai Kembalian
+
+| Tipe                  | Deskripsi                                                                   |
+| --------------------- | --------------------------------------------------------------------------- |
+| `ComputedRef<string>` | Computed Ref Vue yang berisi pathname browser saat ini tanpa awalan locale. |
+
+## Perilaku
+
+- **Penghapusan Locale (Locale stripping)**: Menghapus segmen locale di depan (misalnya `/id/dashboard` → `/dashboard`).
+- **Reaktif**: Memperbarui nilai pada setiap peristiwa `popstate` (navigasi mundur / maju pada browser).
+- **Aman untuk SSR**: Mengembalikan `""` saat `window` tidak tersedia.
+- **Pembersihan (Cleanup)**: Pendengar `popstate` ditambahkan secara global pada saat inisialisasi dan umumnya tidak memerlukan pembersihan manual per-komponen, berkat cara Vue mengelola siklus hidup komponennya.
+
+## Contoh
+
+```vue fileName="src/components/Sidebar.vue"
+<script setup lang="ts">
+import { usePathname } from "vue-intlayer";
+
+const links = [
+  { href: "/dashboard", label: "Dasbor" },
+  { href: "/settings", label: "Pengaturan" },
+];
+
+const pathname = usePathname();
+</script>
+
+<template>
+  <nav>
+    <a
+      v-for="link in links"
+      :key="link.href"
+      :href="link.href"
+      :style="{ fontWeight: pathname === link.href ? 'bold' : 'normal' }"
+    >
+      {{ link.label }}
+    </a>
+  </nav>
+</template>
+```
+
+## Terkait
+
+- [`useLocale`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/id/packages/vue-intlayer/useLocale.md) — locale saat ini + pengalih locale
+- [`getPathWithoutLocale`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/id/packages/intlayer/getPathWithoutLocale.md) — utilitas dasar yang digunakan oleh hook ini

package/docs/id/releases/v6.md

@@ -25,6 +25,10 @@ author: aymericzip
 
 Selamat datang di Intlayer v6! Rilis ini fokus pada performa, pengalaman pengembang, dan keandalan. Berikut adalah sorotan utama, dengan catatan migrasi dan contoh yang bisa langsung disalin-tempel.
 
+## Daftar isi
+
+<TOC levels={[2]} maxDepth={1} />
+
 ## Sorotan
 
 - Perintah baru: `npx intlayer content test` untuk mendeteksi terjemahan yang hilang

package/docs/id/releases/v7.md

@@ -25,6 +25,10 @@ author: aymericzip
 
 Selamat datang di Intlayer v7! Rilis besar ini memperkenalkan peningkatan signifikan dalam performa, keamanan tipe, dan pengalaman pengembang. Berikut adalah sorotan utama, dengan catatan migrasi dan contoh praktis.
 
+## Daftar isi
+
+<TOC levels={[2]} maxDepth={1} />
+
 ## Sorotan
 
 - Strategi caching untuk build yang lebih cepat
@@ -260,6 +264,126 @@ Ini menghasilkan waktu unduh yang lebih cepat dan peningkatan performa runtime u
 
 ---
 
+## Pemformatan Kode Otomatis: konfigurasi formatCommand
+
+v7 memperkenalkan opsi `formatCommand` dalam konfigurasi editor, memungkinkan Anda untuk secara otomatis memformat file konten ketika ditulis oleh Intlayer. Ini memastikan gaya kode dan pemformatan yang konsisten di seluruh file deklarasi konten Anda.
+
+Jika tidak diatur, Intlayer akan mencoba mendeteksi perintah format secara otomatis. Dengan mencoba menyelesaikan perintah berikut: prettier, biome, eslint.
+
+### Konfigurasi
+
+Opsi `formatCommand` menerima template string di mana `{{file}}` akan diganti dengan path file yang sebenarnya:
+
+```typescript fileName="intlayer.config.ts"
+export default {
+  content: {
+    formatCommand: 'bun x biome format "{{file}}" --write --log-level none',
+  },
+};
+```
+
+### Pemformat yang Didukung
+
+Anda dapat menggunakan pemformat kode apa pun yang menerima jalur file sebagai argumen:
+
+**Menggunakan Biome:**
+
+```typescript
+formatCommand: 'bun x biome format "{{file}}" --write --log-level none';
+```
+
+**Menggunakan Prettier:**
+
+```typescript
+formatCommand: 'npx prettier --write "{{file}}" --log-level silent';
+```
+
+**Menggunakan ESLint:**
+
+```typescript
+formatCommand: 'npx eslint --fix "{{file}}" --quiet';
+```
+
+**Menggunakan pemformat bawaan Bun:**
+
+```typescript
+formatCommand: 'bun format "{{file}}"';
+```
+
+### Manfaat
+
+- **Pemformatan konsisten**: Semua file konten diformat secara otomatis sesuai dengan panduan gaya proyek Anda
+- **Pengalaman pengembang**: Tidak perlu memformat file secara manual setelah Intlayer menulisnya
+- **Konsistensi tim**: Memastikan semua anggota tim memiliki pemformatan yang sama diterapkan pada file konten
+- **Integrasi CI/CD**: File konten mempertahankan pemformatan konsisten dalam alur kerja otomatis
+
+### Cara kerjanya
+
+Ketika Intlayer menulis atau memperbarui file deklarasi konten (`.content.ts`, `.content.js`, dll.), ia secara otomatis menjalankan perintah format yang ditentukan pada file tersebut. Placeholder `{{file}}` diganti dengan jalur file aktual, dan perintah dijalankan di direktori dasar proyek.
+
+---
+
+## Konfigurasi Dictionary: Organisasi dan struktur yang lebih baik
+
+v7 memperkenalkan bagian konfigurasi `dictionary` yang baru dan dedicated yang menyediakan organisasi yang lebih baik untuk pengaturan terkait dictionary dan manajemen konten yang ditingkatkan.
+
+### Struktur konfigurasi dictionary baru
+
+Properti `fill` telah dipindahkan dari bagian `content` ke bagian `dictionary` yang baru, memberikan pemisahan kepedulian yang lebih jelas:
+
+**konfigurasi v6:**
+
+```typescript fileName="intlayer.config.ts"
+export default {
+  content: {
+    autoFill: "./{{fileName}}.content.json",
+    contentDir: ["src"],
+  },
+};
+```
+
+**konfigurasi v7:**
+
+```typescript fileName="intlayer.config.ts"
+export default {
+  content: {
+    contentDir: ["src"],
+  },
+  dictionary: {
+    fill: "./{{fileName}}.content.json",
+  },
+};
+```
+
+### Manfaat struktur baru
+
+- **Organisasi yang lebih jelas**: Pengaturan khusus kamus sekarang dikelompokkan bersama
+- **Pemisahan tanggung jawab yang lebih baik**: Penemuan konten vs. operasi kamus dipisahkan dengan jelas
+- **Kemudahan pemeliharaan yang ditingkatkan**: Lebih mudah untuk memahami dan memodifikasi konfigurasi terkait kamus
+- **Ekstensibilitas di masa depan**: Bagian kamus dapat mengakomodasi pengaturan khusus kamus tambahan
+- **Manajemen kamus yang komprehensif**: Mencakup properti seperti `title`, `live`, `priority`, `tags`, `version`, dan `description` untuk membuat dan mengelola kamus baru
+
+### Penggunaan Konfigurasi
+
+Konfigurasi kamus melayani dua tujuan utama:
+
+1. **Nilai Default**: Tentukan nilai default saat membuat file deklarasi konten
+2. **Perilaku Fallback**: Sediakan nilai fallback ketika field spesifik tidak didefinisikan, memungkinkan Anda mendefinisikan perilaku operasi kamus secara global
+
+Bagian kamus mencakup properti komprehensif untuk manajemen kamus:
+
+- **`fill`**: Perilaku auto-fill untuk pembuatan konten
+- **`title`**: Judul default untuk kamus baru
+- **`live`**: Konfigurasi sinkronisasi langsung untuk pembaruan real-time
+- **`priority`**: Pengaturan prioritas untuk resolusi kamus
+- **`tags`**: Tag default untuk organisasi konten
+- **`version`**: Manajemen versi untuk pembaruan kamus
+- **`description`**: Deskripsi default untuk konten baru
+
+Untuk informasi lebih lanjut tentang file deklarasi konten dan bagaimana nilai konfigurasi diterapkan, lihat [Dokumentasi File Konten](https://github.com/aymericzip/intlayer/blob/main/docs/docs/id/dictionary/content_file.md).
+
+---
+
 ## Perintah Fill: Perilaku diperbarui untuk manajemen konten yang lebih baik
 
 v7 memperkenalkan perilaku yang ditingkatkan untuk perintah `fill`, memberikan manajemen konten yang lebih dapat diprediksi dan fleksibel:
@@ -407,6 +531,10 @@ Sistem secara otomatis:
 - **`middleware.prefixDefault`**: Digantikan oleh `routing.mode`
 - **`middleware.noPrefix`**: Digantikan oleh `routing.mode`
 
+### Konfigurasi baru
+
+- **`editor.formatCommand`**: Opsi baru untuk pemformatan kode otomatis pada file konten
+
 ### Pemetaan migrasi
 
 #### Pemetaan konfigurasi

package/docs/id/releases/v9.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-06-14
-updatedAt: 2026-06-14
+updatedAt: 2026-06-23
 title: Intlayer v9 Baru - Apa yang baru?
 description: Temukan apa yang baru di Intlayer v9. Memperkenalkan paket kompatibilitas drop-in untuk pustaka i18n populer dan dukungan untuk Collections, Variants, dan Dynamic Records.
 keywords:
@@ -216,6 +216,42 @@ Pada saat build time, `@intlayer/swc` and `@intlayer/babel` memindai file Anda d
 
 ---
 
+## Vite Plugin: Bundled Compiler & Proxy
+
+Plugin Vite `intlayer()` sekarang menggabungkan **compiler** dan **locale-routing proxy** secara langsung, sehingga sebagian besar proyek hanya memerlukan satu plugin di `vite.config.ts`:
+
+```ts fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import { intlayer } from "vite-intlayer";
+
+export default defineConfig({
+  plugins: [intlayer()],
+});
+```
+
+- **Compiler**: Diaktifkan secara otomatis ketika `compiler.enabled` diatur dan jalur `compiler.output` dikonfigurasi. Anda tidak lagi perlu mendaftarkan `intlayerCompiler()` secara terpisah.
+- **Proxy**: Diaktifkan secara otomatis berdasarkan opsi `routing.enableProxy` yang baru (`true` secara default). Ini menghubungkan middleware deteksi locale / redirect / rewrite dalam pengembangan, preview, dan SSR produksi. Anda tidak lagi perlu mendaftarkan `intlayerProxy()` secara terpisah.
+
+### Opsi `routing.enableProxy`
+
+Opsi baru `routing.enableProxy` mengontrol apakah proxy locale-routing dipasang. Defaultnya adalah `true`. Nonaktifkan ketika Anda ingin menangani locale routing sendiri:
+
+```ts fileName="intlayer.config.ts"
+import type { IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  routing: {
+    enableProxy: false, // Default: true
+  },
+};
+
+export default config;
+```
+
+Plugin standalone `intlayerCompiler()` dan `intlayerProxy()` tetap diekspor untuk setup lanjutan. Mendaftarkan mereka bersama dengan `intlayer()` aman — setiap plugin menghilangkan duplikat dirinya sendiri dan hanya berjalan sekali.
+
+---
+
 ## Catatan migrasi dari v8
 
 Jika Anda memperbarui dari v8, perhatikan bahwa v9 tidak menyertakan breaking changes (perubahan yang merusak). Namun berikut adalah perubahan utamanya:

package/docs/id/roadmap.md

@@ -340,22 +340,6 @@ Intlayer mendukung **TypeScript** (juga JavaScript) dan **JSON** untuk mendeklar
 
 ## Kesimpulan
 
-- Sistem akan menghasilkan terjemahan di latar belakang dan kemudian meminta Anda untuk validasi atau suntingan.
-
-### 4. Peningkatan SEO
-
-- Alat untuk **menganalisis kata kunci**, niat pencarian pengguna, dan tren yang sedang berkembang.
-- Menyarankan konten yang ditingkatkan untuk peringkat yang lebih baik, dan melacak kinerja jangka panjang.
-
-### 5. Kompatibilitas dengan Lebih Banyak Framework
-
-- Upaya sedang dilakukan untuk mendukung **Solid, Svelte, Angular**, dan lainnya.
-- Bertujuan agar Intlayer kompatibel dengan **aplikasi berbasis JavaScript apa pun**.
-
----
-
-## Kesimpulan
-
 Intlayer bertujuan menjadi solusi satu atap untuk manajemen konten dan internasionalisasi. Fokusnya pada fleksibilitas (file terpusat atau terdistribusi), dukungan bahasa yang luas, integrasi mudah dengan framework dan bundler modern, serta fitur bertenaga AI yang kuat. Seiring dengan hadirnya kemampuan baru, seperti pengujian A/B, versioning, dan terjemahan otomatis, Intlayer akan terus menyederhanakan alur kerja konten dan meningkatkan pengalaman pengguna di berbagai platform.
 
 Tetap nantikan rilis berikutnya, dan jangan ragu untuk menjelajahi fitur yang ada untuk melihat bagaimana Intlayer dapat membantu memusatkan dan mengoptimalkan proses manajemen konten Anda hari ini!

package/docs/it/CI_CD.md

@@ -26,6 +26,10 @@ author: aymericzip
 
 Intlayer consente la generazione automatica delle traduzioni per i tuoi file di dichiarazione dei contenuti. Ci sono diversi modi per raggiungere questo obiettivo a seconda del tuo flusso di lavoro.
 
+## Indice dei contenuti
+
+<TOC/>
+
 ## Utilizzo del CMS
 
 Con Intlayer, puoi adottare un flusso di lavoro in cui viene dichiarata localmente una sola lingua, mentre tutte le traduzioni sono gestite da remoto tramite il CMS. Questo permette che contenuti e traduzioni siano completamente separati dal codice, offrendo maggiore flessibilità agli editor di contenuti e abilitando il caricamento dinamico dei contenuti (senza bisogno di ricostruire l'applicazione per applicare le modifiche).

package/docs/it/autoFill.md

@@ -28,6 +28,53 @@ history:
 author: aymericzip
 ---
 
+# Riempi le traduzioni dei file di dichiarazione del contenuto
+
+**L'autofill dei file di dichiarazione del contenuto** nella tua CI è un modo per accelerare il tuo workflow di sviluppo.
+
+## Comprensione del comportamento
+
+Il comando `fill` include due modalità:
+
+- **Complete**: Riempie automaticamente tutti i contenuti mancanti per ogni locale e modifica il file corrente, o un altro file se specificato. In altre parole, la modalità complete salterà la traduzione dei contenuti già esistenti, se già tradotti.
+- **Review**: Riempie automaticamente **tutti** i contenuti per ogni locale e genera per un file specifico, o un altro file se specificato.
+
+Il comando will elaborerà tutti i file di dichiarazione del contenuto locale. In altre parole, non elaborerà i tuoi contenuti remoti dal CMS. Il CMS include la propria gestione delle traduzioni.
+Se utilizzi plugin come `@intlayer/sync-json-plugin`, Intlayer trasformerà i file JSON in file di dichiarazione del contenuto locale. In altre parole, verranno elaborati dal comando `fill`.
+
+I nuovi file generati includono un'istruzione `filled` come metadati del dizionario. Questa istruzione verrà utilizzata da Intlayer per sapere se il file è stato riempito automaticamente o meno, e saltare questo file dalla traduzione nuovamente se presente.
+
+Intlayer considererà anche le seguenti istruzioni per il riempimento automatico:
+
+- Dal tuo `.content.{ts|js|json}` → istruzione `fill`
+- Dal tuo file di configurazione `.intlayer.config.ts` → istruzione `dictionary.fill`
+- Verrà impostato su `true` per impostazione predefinita altrimenti
+
+Per i file di dichiarazione del contenuto per locale, l'istruzione `true` verrà sostituita da `./{{fileName}}.fill.content.json`. Questo è perché un file di dichiarazione del contenuto per locale non può ricevere contenuti localizzati aggiuntivi. Quindi genererà un nuovo file per non sovrascrivere il file esistente.
+
+## Comportamento Predefinito
+
+Per impostazione predefinita, `fill` è impostato su `true` a livello globale, il che significa che Intlayer compilerà automaticamente tutti i file di contenuto e modificherà il file stesso. Questo comportamento può essere personalizzato in diversi modi:
+
+### Opzioni di Configurazione Globale
+
+1. **`fill: true` (default)** - Riempie automaticamente tutte le locale e modifica il file corrente
+2. **`fill: false`** - Disabilita il riempimento automatico per questo file di contenuto
+3. **`fill: "./relative/path/to/file"`** - Crea/aggiorna il file specificato senza modificare quello corrente puntando a un percorso relativo risolto in base alla posizione del file corrente
+4. **`fill: "/absolute/path/to/file"`** - Crea/aggiorna il file specificato senza modificare quello corrente puntando a un percorso relativo risolto in base alla posizione della directory base (campo `baseDir` nel file di configurazione `.intlayer.config.ts`)
+5. **`fill: "C:\\absolute\path\to\file"`** - Crea/aggiorna il file specificato senza modificare quello corrente puntando a un percorso assoluto risolto in base al tuo sistema operativo
+6. **`fill: { [key in Locales]?: string }`** - Crea/aggiorna il file specificato per ogni locale
+
+### Modifiche di comportamento in v7
+
+In v7, il comportamento del comando `fill` è stato aggiornato:
+
+- **`fill: true`** - Riscrive il file corrente con il contenuto compilato per tutte le lingue
+- **`fill: "path/to/file"`** - Compila il file specificato senza modificare il file corrente
+- **`fill: false`** - Disabilita completamente l'auto-compilazione
+
+Quando si utilizza un'opzione di percorso per scrivere in un altro file, il meccanismo di compilazione funziona attraverso una relazione _master-slave_ tra i file di dichiarazione del contenuto. Il file principale (master) funge da fonte di verità, e quando viene aggiornato, Intlayer applicherà automaticamente tali modifiche ai file di dichiarazione derivati (compilati) specificati dal percorso.
+
 # Traduzioni dei File di Dichiarazione del Contenuto con Compilazione Automatica
 
 I **file di dichiarazione del contenuto con compilazione automatica** sono un modo per velocizzare il tuo flusso di lavoro di sviluppo.
@@ -88,6 +135,40 @@ Intlayer genererà automaticamente il file di dichiarazione derivato in `src/com
 
 Successivamente, entrambi i file di dichiarazione saranno uniti in un unico dizionario, accessibile tramite il consueto hook `useIntlayer("example")` (react) / composable (vue).
 
+## Configurazione Globale
+
+Puoi configurare la configurazione di riempimento automatico globale nel file `intlayer.config.ts`.
+
+```ts fileName="intlayer.config.ts"
+import { type IntlayerConfig, Locales } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+    requiredLocales: [Locales.ENGLISH, Locales.FRENCH],
+  },
+  dictionary: {
+    // Genera automaticamente le traduzioni mancanti per tutti i dizionari
+    fill: "./{{fileName}}Filled.content.ts",
+    //
+    // fill: "/messages/{{locale}}/{{key}}/{{fileName}}.content.json",
+    //
+    // fill: true, // genera automaticamente le traduzioni mancanti per tutti i dizionari come se usassi "./{{fileName}}.content.json"
+    //
+    // fill: {
+    //   en: "./{{fileName}}.en.content.json",
+    //   fr: "./{{fileName}}.fr.content.json",
+    //   es: "./{{fileName}}.es.content.json",
+    // },
+  },
+};
+
+export default config;
+```
+
+Puoi comunque mettere a punto per singolo dizionario utilizzando il campo `fill` nei file di contenuto. Intlayer considererà prima la configurazione per singolo dizionario e poi ricorrerà alla configurazione globale.
+
 ## Formato del File Compilato Automaticamente
 
 Il formato consigliato per i file di dichiarazione compilati automaticamente è **JSON**, che aiuta a evitare vincoli di formattazione. Tuttavia, Intlayer supporta anche i formati `.ts`, `.js`, `.mjs`, `.cjs` e altri.

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/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/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.