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

package/docs/it/packages/react-intlayer/useIntlayer.md

@@ -29,49 +29,6 @@ author: aymericzip
 
 Questa sezione fornisce una guida dettagliata sull'uso dell'hook `useIntlayer` all'interno delle applicazioni React, permettendo una localizzazione efficiente dei contenuti.
 
-## Importare `useIntlayer` in React
-
-L'hook `useIntlayer` può essere integrato nelle applicazioni React importandolo in base al contesto:
-
-- **Componente Client:**
-
-  ```typescript codeFormat="typescript"
-  import { useIntlayer } from "react-intlayer"; // Usato nei componenti React lato client
-  ```
-
-  ```javascript codeFormat="esm"
-  import { useIntlayer } from "react-intlayer"; // Usato nei componenti React lato client
-  ```
-
-  ```javascript codeFormat="commonjs"
-  const { useIntlayer } = require("react-intlayer"); // Usato nei componenti React lato client
-  ```
-
-- **Componente Server:**
-
-  ```typescript codeFormat="commonjs"
-  import { useIntlayer } from "react-intlayer/server"; // Usato nei componenti React lato server
-  ```
-
-  ```javascript codeFormat="esm"
-  import { useIntlayer } from "react-intlayer/server"; // Usato nei componenti React lato server
-  ```
-
-  ```javascript codeFormat="commonjs"
-  const { useIntlayer } = require("react-intlayer/server"); // Usato nei componenti React lato server
-  ```
-
-## Parametri
-
-L'hook accetta due parametri:
-
-1. **`key`**: La chiave del dizionario per recuperare il contenuto localizzato.
-2. **`locale`** (opzionale): La localizzazione desiderata. Di default è la localizzazione del contesto se non specificata.
-
-## Dizionario
-
-Tutte le chiavi del dizionario devono essere dichiarate all'interno dei file di dichiarazione dei contenuti per migliorare la sicurezza dei tipi ed evitare errori. Puoi trovare le [istruzioni di configurazione qui](https://github.com/aymericzip/intlayer/blob/main/docs/docs/it/dictionary/content_file.md).
-
 ## Esempio di utilizzo in React
 
 Dimostrazione dell'hook `useIntlayer` all'interno di un componente React:
@@ -134,20 +91,6 @@ const ServerComponentExample = () => {
 };
 ```
 
-## Gestione degli attributi
-
-Quando si localizzano gli attributi, accedere ai valori del contenuto in modo appropriato:
-
-```jsx
-<button title={content.buttonTitle.value}>{content.buttonText}</button>
-```
-
-## Risorse aggiuntive
-
-- **Editor Visivo Intlayer**: Per un'esperienza di gestione dei contenuti più intuitiva, fare riferimento alla documentazione dell'editor visivo [qui](https://github.com/aymericzip/intlayer/blob/main/docs/docs/it/intlayer_visual_editor.md).
-
-Questa sezione si rivolge specificamente all'integrazione del hook `useIntlayer` nelle applicazioni React, semplificando il processo di localizzazione e garantendo la coerenza dei contenuti tra le diverse località.
-
 ## Risorse Aggiuntive
 
 - **Intlayer Visual Editor**: Per un'esperienza di gestione dei contenuti più intuitiva, fare riferimento alla documentazione dell'editor visuale [qui](https://github.com/aymericzip/intlayer/blob/main/docs/docs/it/intlayer_visual_editor.md).

package/docs/it/releases/v6.md

@@ -25,6 +25,10 @@ author: aymericzip
 
 Benvenuto in Intlayer v6! Questa versione si concentra su prestazioni, esperienza dello sviluppatore e affidabilità. Di seguito i punti salienti, con note di migrazione ed esempi da copiare e incollare.
 
+## Sommario
+
+<TOC levels={[2]} maxDepth={1} />
+
 ## Punti salienti
 
 - Nuovo comando: `npx intlayer content test` per rilevare le traduzioni mancanti
@@ -294,6 +298,24 @@ Vedi [CMS e Live Sync](https://github.com/aymericzip/intlayer/blob/main/docs/doc
 
 ---
 
+## Processo parallelo per monitorare i file su turbopack
+
+Quando si utilizza Turbopack su Next.js 14 e versioni successive come server di sviluppo con il comando `next dev --turbopack`, le modifiche al dizionario non verranno rilevate automaticamente per impostazione predefinita.
+
+Questa limitazione si verifica perché Turbopack non può eseguire plugin webpack in parallelo per monitorare le modifiche nei file di contenuto.
+
+Per aggirare questo problema, abbiamo utilizzato il comando `intlayer watch`, usando l'opzione `--with` per eseguire contemporaneamente sia il server di sviluppo che il watcher di build di Intlayer.
+
+```json5 fileName="package.json"
+{
+  "scripts": {
+    "dev": "npx intlayer watch --with 'next dev --turbopack'",
+  },
+}
+```
+
+---
+
 ## Note sulla migrazione
 
 - Rimosso: `dictionaryOutput` (precedentemente `i18next` o `next-intl`). Tornerà come adattatori pluggabili nelle versioni future. Rimuovi il campo dalla tua configurazione.
@@ -312,6 +334,12 @@ Vedi [CMS e Live Sync](https://github.com/aymericzip/intlayer/blob/main/docs/doc
 
 ---
 
+## Note sulla migrazione da v6 a v7
+
+Consulta le [note sulla migrazione da v6 a v7](https://github.com/aymericzip/intlayer/blob/main/docs/docs/it/releases/v7.md) per ulteriori informazioni.
+
+---
+
 ## Link utili
 
 - [Riferimento CLI](https://github.com/aymericzip/intlayer/blob/main/docs/docs/it/cli/index.md)

package/docs/it/releases/v7.md

@@ -25,6 +25,10 @@ author: aymericzip
 
 Benvenuto in Intlayer v7! Questa versione principale introduce miglioramenti significativi nelle prestazioni, nella sicurezza dei tipi e nell'esperienza dello sviluppatore. Di seguito i punti salienti, con note di migrazione ed esempi pratici.
 
+## Indice
+
+<TOC levels={[2]} maxDepth={1} />
+
 ## Punti salienti
 
 - Strategia di caching per build più veloci
@@ -262,6 +266,126 @@ Questo si traduce in tempi di download più rapidi e prestazioni di runtime migl
 
 ---
 
+## Formattazione automatica del codice: configurazione formatCommand
+
+v7 introduce l'opzione `formatCommand` nella configurazione dell'editor, permettendoti di formattare automaticamente i file di contenuto quando vengono scritti da Intlayer. Questo assicura uno stile di codice e una formattazione coerenti nei tuoi file di dichiarazione di contenuto.
+
+Se non impostato, Intlayer tenterà di rilevare il comando di formattazione automaticamente. Provando a risolvere i seguenti comandi: prettier, biome, eslint.
+
+### Configurazione
+
+L'opzione `formatCommand` accetta un template di stringa dove `{{file}}` verrà sostituito con il percorso file effettivo:
+
+```typescript fileName="intlayer.config.ts"
+export default {
+  content: {
+    formatCommand: 'bun x biome format "{{file}}" --write --log-level none',
+  },
+};
+```
+
+### Formatter supportati
+
+Puoi utilizzare qualsiasi code formatter che accetta percorsi di file come argomenti:
+
+**Usando Biome:**
+
+```typescript
+formatCommand: 'bun x biome format "{{file}}" --write --log-level none';
+```
+
+**Usando Prettier:**
+
+```typescript
+formatCommand: 'npx prettier --write "{{file}}" --log-level silent';
+```
+
+**Usando ESLint:**
+
+```typescript
+formatCommand: 'npx eslint --fix "{{file}}" --quiet';
+```
+
+**Usando il formatter built-in di Bun:**
+
+```typescript
+formatCommand: 'bun format "{{file}}"';
+```
+
+### Vantaggi
+
+- **Formattazione coerente**: Tutti i file di contenuto vengono formattati automaticamente secondo le linee guida di stile del tuo progetto
+- **Esperienza dello sviluppatore**: Non è necessario formattare manualmente i file dopo che Intlayer li scrive
+- **Coerenza del team**: Garantisce che tutti i membri del team abbiano la stessa formattazione applicata ai file di contenuto
+- **Integrazione CI/CD**: I file di contenuto mantengono una formattazione coerente nei flussi di lavoro automatizzati
+
+### Come funziona
+
+Quando Intlayer scrive o aggiorna un file di dichiarazione del contenuto (`.content.ts`, `.content.js`, ecc.), esegue automaticamente il comando di formattazione specificato sul file. Il placeholder `{{file}}` viene sostituito con il percorso file effettivo e il comando viene eseguito nella directory base del progetto.
+
+---
+
+## Configurazione del dizionario: Migliore organizzazione e struttura
+
+v7 introduce una nuova sezione di configurazione dedicata `dictionary` che fornisce una migliore organizzazione per le impostazioni relative al dizionario e una gestione dei contenuti migliorata.
+
+### Nuova struttura di configurazione del dizionario
+
+La proprietà `fill` è stata spostata dalla sezione `content` a una nuova sezione `dictionary`, fornendo una separazione più chiara delle responsabilità:
+
+**Configurazione v6:**
+
+```typescript fileName="intlayer.config.ts"
+export default {
+  content: {
+    autoFill: "./{{fileName}}.content.json",
+    contentDir: ["src"],
+  },
+};
+```
+
+**Configurazione v7:**
+
+```typescript fileName="intlayer.config.ts"
+export default {
+  content: {
+    contentDir: ["src"],
+  },
+  dictionary: {
+    fill: "./{{fileName}}.content.json",
+  },
+};
+```
+
+### Vantaggi della nuova struttura
+
+- **Organizzazione più chiara**: Le impostazioni specifiche del dizionario sono ora raggruppate insieme
+- **Migliore separazione delle responsabilità**: La scoperta dei contenuti rispetto alle operazioni del dizionario sono chiaramente separate
+- **Manutenibilità migliorata**: Più facile da comprendere e modificare le configurazioni relative al dizionario
+- **Estensibilità futura**: La sezione del dizionario può contenere impostazioni specifiche del dizionario aggiuntive
+- **Gestione dizionario completa**: Include proprietà come `title`, `live`, `priority`, `tags`, `version` e `description` per creare e gestire nuovi dizionari
+
+### Utilizzo della configurazione
+
+La configurazione del dizionario serve a due scopi principali:
+
+1. **Valori predefiniti**: Definire i valori predefiniti durante la creazione di file di dichiarazione del contenuto
+2. **Comportamento di fallback**: Fornire valori di fallback quando campi specifici non sono definiti, consentendoti di definire il comportamento dell'operazione del dizionario globalmente
+
+La sezione del dizionario include proprietà complete per la gestione del dizionario:
+
+- **`fill`**: Comportamento di riempimento automatico per la generazione del contenuto
+- **`title`**: Titolo predefinito per i nuovi dizionari
+- **`live`**: Configurazione di sincronizzazione live per gli aggiornamenti in tempo reale
+- **`priority`**: Impostazioni di priorità per la risoluzione del dizionario
+- **`tags`**: Tag predefiniti per l'organizzazione del contenuto
+- **`version`**: Gestione della versione per gli aggiornamenti del dizionario
+- **`description`**: Descrizione predefinita per i nuovi contenuti
+
+Per ulteriori informazioni sui file di dichiarazione del contenuto e su come vengono applicate le impostazioni di configurazione, consulta la [Documentazione del file di contenuto](https://github.com/aymericzip/intlayer/blob/main/docs/docs/it/dictionary/content_file.md).
+
+---
+
 ## Comando Fill: comportamento aggiornato per una migliore gestione dei contenuti
 
 La versione 7 introduce un comportamento migliorato per il comando `fill`, offrendo una gestione dei contenuti più prevedibile e flessibile:
@@ -409,6 +533,10 @@ Il sistema automaticamente:
 - **`middleware.prefixDefault`**: Sostituito da `routing.mode`
 - **`middleware.noPrefix`**: Sostituito da `routing.mode`
 
+### Nuove configurazioni
+
+- **`editor.formatCommand`**: Nuova opzione per la formattazione automatica del codice dei file di contenuto
+
 ### Mappatura della migrazione
 
 #### Mappatura della configurazione

package/docs/it/releases/v9.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-06-14
-updatedAt: 2026-06-14
+updatedAt: 2026-06-23
 title: Nuovo Intlayer v9 - Cosa c'è di nuovo?
 description: Scopri le novità di Intlayer v9. Introduzione di package di compatibilità drop-in per le più diffuse librerie i18n e supporto per Collections, Variants e Dynamic Records.
 keywords:
@@ -216,6 +216,42 @@ In fase di build, `@intlayer/swc` e `@intlayer/babel` scansionano i tuoi file e
 
 ---
 
+## Vite Plugin: Compiler e Proxy in Bundle
+
+Il plugin Vite `intlayer()` ora raggruppa il **compiler** e il **proxy di locale-routing** direttamente, quindi la maggior parte dei progetti ha bisogno solo di un singolo plugin in `vite.config.ts`:
+
+```ts fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import { intlayer } from "vite-intlayer";
+
+export default defineConfig({
+  plugins: [intlayer()],
+});
+```
+
+- **Compiler**: Si attiva automaticamente quando `compiler.enabled` è impostato e un percorso `compiler.output` è configurato. Non è più necessario registrare `intlayerCompiler()` separatamente.
+- **Proxy**: Si attiva automaticamente in base alla nuova opzione `routing.enableProxy` (`true` per impostazione predefinita). Collega il middleware di rilevamento locale / reindirizzamento / riscrittura in sviluppo, anteprima e SSR in produzione. Non è più necessario registrare `intlayerProxy()` separatamente.
+
+### Opzione `routing.enableProxy`
+
+Una nuova opzione `routing.enableProxy` controlla se il proxy di routing per le locale è attivo. Il valore predefinito è `true`. Disabilitalo quando desideri gestire il routing delle locale autonomamente:
+
+```ts fileName="intlayer.config.ts"
+import type { IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  routing: {
+    enableProxy: false, // Default: true
+  },
+};
+
+export default config;
+```
+
+I plugin standalone `intlayerCompiler()` e `intlayerProxy()` rimangono esportati per configurazioni avanzate. Registrarli insieme a `intlayer()` è sicuro — ogni plugin si deduplica e viene eseguito una sola volta.
+
+---
+
 ## Note di migrazione da v8
 
 Se stai eseguendo l'aggiornamento da v8, nota che la v9 non include breaking changes. Ma ecco le modifiche chiave:

package/docs/it/roadmap.md

@@ -29,6 +29,12 @@ Intlayer è una soluzione per la gestione dei contenuti e l'internazionalizzazio
 
 ---
 
+## Sommario
+
+<TOC/>
+
+---
+
 ## Funzionalità Attuali
 
 ### 1. Dichiarazione dei Contenuti

package/docs/ja/CI_CD.md

@@ -30,6 +30,10 @@ Intlayer は、コンテンツ宣言ファイルの翻訳を自動生成する
 
 Intlayer を使用すると、ローカルでは単一のロケールのみを宣言し、すべての翻訳は CMS を通じてリモートで管理するワークフローを採用できます。これにより、コンテンツと翻訳がコードベースから完全に切り離され、コンテンツ編集者にとってより柔軟性が提供され、ホットコンテンツリロード（変更を適用するためにアプリケーションを再ビルドする必要なし）が可能になります。
 
+## CMSを使用する
+
+Intlayerを使用すると、単一のロケールのみをローカルで宣言し、すべての翻訳をCMSを介してリモートで管理するワークフローを採用できます。これにより、コンテンツと翻訳をコードベースから完全に分離でき、コンテンツエディターに対しより高い柔軟性を提供し、Live Sync（アプリケーションを再構築することなく変更を適用）を有効にします。
+
 ### 設定例
 
 ```ts fileName="intlayer.config.ts"

package/docs/ja/autoFill.md

@@ -28,6 +28,53 @@ history:
 author: aymericzip
 ---
 
+# コンテンツ宣言ファイルの翻訳を自動入力
+
+**CI でのコンテンツ宣言ファイルの自動入力**は、開発ワークフローを高速化する方法です。
+
+## 動作の理解
+
+`fill` コマンドには2つのモードがあります：
+
+- **Complete**: 各ロケールのすべての欠落コンテンツを自動的に入力し、現在のファイルまたは指定された別のファイルを編集します。つまり、完全モードは既に翻訳されている既存コンテンツのスキップします。
+- **Review**: 各ロケールのすべてのコンテンツを自動的に入力し、特定のファイルまたは指定された別のファイルを生成します。
+
+`fill` コマンドはすべてのロケールコンテンツ宣言ファイルを処理します。つまり、CMSからのリモートコンテンツは処理しません。CMSは独自の翻訳管理を含んでいます。
+`@intlayer/sync-json-plugin` などのプラグインを使用する場合、Intlayerはこれらのファイルをロケールコンテンツ宣言ファイルに変換します。つまり、これらのファイルは `fill` コマンドによって処理されます。
+
+新しく生成されたファイルには、辞書メタデータとして `filled` 命令が含まれています。この命令は、Intlayerがファイルが自動入力されたかどうかを判定し、存在する場合はこのファイルを再度翻訳の対象からスキップするために使用されます。
+
+Intlayerは自動入力に関して以下の命令を考慮します：
+
+- `.content.{ts|js|json}` ファイルから → `fill` 命令
+- 設定ファイル `.intlayer.config.ts` から → `dictionary.fill` 命令
+- それ以外の場合はデフォルトで `true` に設定されます
+
+ロケール固有のコンテンツ宣言ファイルの場合、`true` 命令は `./{{fileName}}.fill.content.json` に置き換えられます。これは、ロケール固有のコンテンツ宣言ファイルが追加のローカライズされたコンテンツを受け取ることができないためです。そのため、既存のファイルを上書きしないために新しいファイルを生成します。
+
+## デフォルト動作
+
+デフォルトでは、`fill`はグローバルに`true`に設定されています。これは、Intlayerがすべてのコンテンツファイルを自動的に入力し、ファイル自体を編集することを意味します。この動作は、いくつかの方法でカスタマイズできます。
+
+### グローバル設定オプション
+
+1. **`fill: true` (デフォルト)** - すべてのロケールを自動的に埋め、現在のファイルを編集します
+2. **`fill: false`** - このコンテンツファイルの自動埋めを無効にします
+3. **`fill: "./relative/path/to/file"`** - 現在のファイルを編集せずに指定されたファイルを作成/更新します。相対パスは現在のファイルの場所に基づいて解決されます
+4. **`fill: "/absolute/path/to/file"`** - 現在のファイルを編集せずに指定されたファイルを作成/更新します。相対パスは基本ディレクトリの場所に基づいて解決されます（設定ファイル `.intlayer.config.ts` の `baseDir` フィールド）
+5. **`fill: "C:\\absolute\path\to\file"`** - 現在のファイルを編集せずに指定されたファイルを作成/更新します。絶対パスはお使いのオペレーティングシステムに基づいて解決されます
+6. **`fill: { [key in Locales]?: string }`** - 各ロケールについて指定されたファイルを作成/更新します
+
+### v7 の動作変更
+
+v7 では、`fill` コマンドの動作が更新されました：
+
+- **`fill: true`** - 現在のファイルを全ロケールの埋め込みコンテンツで上書きします
+- **`fill: "path/to/file"`** - 指定されたファイルを埋め込みますが、現在のファイルは変更しません
+- **`fill: false`** - 自動埋め込みを完全に無効にします
+
+別のファイルに書き込むためのパスオプションを使用する場合、埋め込みメカニズムはコンテンツ宣言ファイル間の _マスター・スレーブ_ 関係を通じて機能します。メインファイル（マスター）が情報源として機能し、更新されると、Intlayer はパスで指定されたスレーブの宣言ファイルに変更を自動的に適用します。
+
 # 自動入力コンテンツ宣言ファイルの翻訳
 
 **自動入力コンテンツ宣言ファイル**は、開発ワークフローを高速化する方法です。
@@ -88,6 +135,40 @@ Intlayer は、メインファイルにまだ宣言されていないすべて
 
 その後、両方の宣言ファイルは単一の辞書にマージされ、標準の `useIntlayer("example")` フック（React）/ コンポーザブル（Vue）を使ってアクセス可能になります。
 
+## グローバル設定
+
+`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: {
+    // すべての辞書に対して欠落している翻訳を自動生成します
+    fill: "./{{fileName}}Filled.content.ts",
+    //
+    // fill: "/messages/{{locale}}/{{key}}/{{fileName}}.content.json",
+    //
+    // fill: true, // "./{{fileName}}.content.json" を使用しているようなすべての辞書に対して欠落している翻訳を自動生成します
+    //
+    // fill: {
+    //   en: "./{{fileName}}.en.content.json",
+    //   fr: "./{{fileName}}.fr.content.json",
+    //   es: "./{{fileName}}.es.content.json",
+    // },
+  },
+};
+
+export default config;
+```
+
+コンテンツファイルの `fill` フィールドを使用して、辞書ごとに細かく調整することもできます。Intlayer は最初に辞書ごとの設定を検討し、その後グローバル設定にフォールバックします。
+
 ## 自動補完されたファイル形式
 
 自動補完された宣言ファイルに推奨される形式は **JSON** であり、これによりフォーマットの制約を回避できます。ただし、Intlayer は `.ts`、`.js`、`.mjs`、`.cjs` などの他の形式もサポートしています。

package/docs/ja/benchmark/solid.md

@@ -118,6 +118,28 @@ i18nリークの問題を素早く特定するために、無料のスキャナ
 - **名前空間付き静的（Scoped static）**: 複雑な追加リクエストなしで、コードを整理（論理的分離）した状態に保つ。
 - **名前空間付き動的（Scoped dynamic）**: コード分割とパフォーマンスのための最善のアプローチ。現在のビューとアクティブなロケールに必要なものだけをロードし、メモリ使用量を最小限に抑える。
 
+### 測定内容:
+
+実際のブラウザで各スタック向けに同じ多言語アプリを実行し、実際にどのようなデータが送信されたか、処理にどのくらい時間がかかったかを記録しました。サイズは**通常のウェブ圧縮後**に報告されています。これは生のソースコードのサイズよりも、実際にユーザーがダウンロードするものに近いためです。
+
+- **国際化ライブラリサイズ**: バンドリング、ツリーシェイキング、およびミニフィケーション後、i18nライブラリのサイズは、空のコンポーネント内のプロバイダー + フック/プリミティブコードのサイズです。翻訳ファイルの読み込みは含まれていません。コンテンツが入る前に、ライブラリがどのくらい高コストかを示します。
+
+- **ページごとのJavaScript**: 各ベンチマークルートについて、そのアクセス時にブラウザが引き込むスクリプトの量。スイート内のページ間で平均化されます（レポートがロールアップする場合はロケール間でも）。ヘビーページは遅いページです。
+
+- **他のロケールからのリーク**: 監査対象ページで誤って読み込まれるはずの、別の言語の同じページのコンテンツです。このコンテンツは不要であり、回避すべきです。（例: `/en/about`ページバンドル内の`/fr/about`ページコンテンツ）
+
+- **他のルートからのリーク**: **他の画面**についても同じ考え方です。1つのページを開いたときに、その他のページのコピーが一緒に読み込まれるかどうかです。（例: `/en/contact`ページバンドル内の`/en/about`ページコンテンツ）。スコアが高いことは、弱い分割またはバンドルが過度に広いことを示唆しています。
+
+- **平均コンポーネントバンドルサイズ**: 一般的なUIピースは、1つの巨大なアプリ番号の内部に隠れるのではなく、**1つずつ**測定されます。国際化が日常的なコンポーネントを静かに膨張させているかどうかを示します。例えば、コンポーネントが再レンダリングされる場合、メモリからすべてのデータを読み込みます。巨大なJSONを任意のコンポーネントに添付することは、コンポーネントのパフォーマンスを低下させる大量の未使用データを接続するようなものです。
+
+- **言語切り替えの応答性**: アプリ自身のコントロールを使って言語を切り替え、ページが明確に切り替わるまでにかかる時間を測定します。これは実験室のマイクロステップではなく、訪問者が気付くものです。
+
+- **言語変更後のレンダリング作業**: より狭いフォローアップです。切り替えが実行されている間に、新しい言語のために、インターフェイスの再描画にどのくらいの労力がかかったかです。「感じられた」時間とフレームワークのコストが異なる場合に役立ちます。
+
+- **初期ページ読み込み時間**: ナビゲーションからブラウザがテストしたシナリオのページが完全に読み込まれたと判断するまで。コールドスタートの比較に適しています。
+
+- **ハイドレーション時間**: アプリがそれを公開する場合、クライアントがサーバーHTMLを実際にクリック可能な状態に変えるのにかかる時間です。表の中のダッシュは、その実装がこのベンチマークで信頼できるハイドレーション数値を提供しなかったことを意味します。
+
 ## GitHubのスター
 
 GitHubのスターは、プロジェクトの普及度、コミュニティの信頼、および長期的な関連性を示す強力な指標です。技術的な品質を直接測定するものではありませんが、どれだけの開発者がプロジェクトを有用だと感じ、その進捗をフォローし、採用する可能性があるかを反映しています。プロジェクトの価値を見積もる際、スターは代替案との勢いの比較を助け、エコシステムの成長に関する洞察を提供します。

package/docs/ja/benchmark/svelte.md

@@ -116,6 +116,28 @@ i18nリークの問題を素早く特定するために、無料のスキャナ
 - **名前空間付き静的（Scoped static）**: 複雑な追加リクエストなしで、コードを整理（論理的分離）した状態に保つ。
 - **名前空間付き動的（Scoped dynamic）**: コード分割とパフォーマンスのための最善のアプローチ。現在のビューとアクティブなロケールに必要なものだけをロードし、メモリ使用量を最小限に抑える。
 
+### 測定内容：
+
+実際のブラウザで各スタックの同じ多言語アプリを実行し、実際にネットワークに送信されたものと処理時間を記録しました。サイズは**通常のウェブ圧縮後**に報告されています。これはユーザーがダウンロードする実際のサイズに近いため、生のソースコード数よりも適切です。
+
+- **国際化ライブラリのサイズ**: バンドリング、ツリーシェイキング、ミニフィケーション後の i18n ライブラリのサイズは、空のコンポーネント内のプロバイダー + ストアコードのサイズです。翻訳ファイルの読み込みは含まれていません。これはコンテンツが含まれる前にライブラリにかかるコストを示します。
+
+- **ページごとの JavaScript**: 各ベンチマークルートについて、そのアクセス時にブラウザが取得するスクリプトの量。スイート内のページとロケール全体で平均化されています（レポートにまとめられている場合）。重いページは遅いページです。
+
+- **他のロケールからのリーク**: 監査対象ページに誤って読み込まれる、別の言語での同じページのコンテンツです。このコンテンツは不要であり、避けるべきです。（例：`/en/about` ページバンドル内の `/fr/about` ページコンテンツ）
+
+- **他のルートからのリーク**: **他の画面**についても同じ考え方です。1 つのページを開いただけなのに、そのコピーが一緒に読み込まれるかどうかです。（例：`/en/contact` ページバンドル内の `/en/about` ページコンテンツ）。高いスコアは分割が弱いか、バンドルが広すぎることを示唆しています。
+
+- **コンポーネントバンドルサイズの平均**: 一般的な UI パーツは 1 つずつ測定され、1 つの巨大なアプリ数に隠れていません。これは国際化がいかに日常的なコンポーネントを静かに膨張させるかを示しています。例えば、コンポーネントが再レンダリングされる場合、メモリからそのすべてのデータを読み込みます。巨大な JSON をコンポーネントに接続することは、コンポーネントのパフォーマンスを低下させる大量の未使用データストアに接続するようなものです。
+
+- **言語切り替えの応答性**: アプリの独自のコントロールを使用して言語を切り替え、ページが明らかに切り替わるまでにかかる時間を計測します。これは訪問者が気付く、ラボのマイクロステップではありません。
+
+- **言語変更後のレンダリング作業**: より狭い範囲のフォローアップです。スイッチが実行中になった後、新しい言語に対して再描画するためにインターフェースがどれだけの労力を費やしたかです。「体感」時間とフレームワークのコストが異なる場合に役立ちます。
+
+- **初期ページ読み込み時間**: ナビゲーションからブラウザがテストシナリオのページが完全に読み込まれたと判断するまで。コールドスタートを比較するのに最適です。
+
+- **ハイドレーション時間**: アプリが公開している場合、クライアントがサーバー HTML を実際にクリックできるものに変える際にかかる時間です。テーブル内のダッシュは、その実装がこのベンチマークで信頼できるハイドレーション数値を提供しなかったことを意味します。
+
 ## GitHubのスター
 
 GitHubのスターは、プロジェクトの普及度、コミュニティの信頼、および長期的な関連性を示す強力な指標です。技術的な品質を直接測定するものではありませんが、どれだけの開発者がプロジェクトを有用だと感じ、その進捗をフォローし、採用する可能性があるかを反映しています。プロジェクトの価値を見積もる際、スターは代替案との勢いの比較を助け、エコシステムの成長に関する洞察を提供します。

package/docs/ja/benchmark/tanstack.md

@@ -124,6 +124,28 @@ i18nのリーク問題を素早く特定するために、無料のスキャナ
 - **Scoped static**: 複雑な追加ネットワークリクエストなしで、コードを整理（論理的な分離）できる。
 - **Scoped dynamic**: コード分割とパフォーマンスにおいて最良のアプローチ。現在のビューとアクティブなロケールが必要なものだけをロードすることで、メモリ使用量を最小限に抑える。
 
+### 測定内容:
+
+私は、すべてのスタックに対して同じ多言語アプリを実際のブラウザで実行し、実際にネットワークを通じて何が表示されたか、どのくらい時間がかかったかを記録しました。サイズは**通常のウェブ圧縮後**に報告されています。これは生ソースコード数よりも、人々が実際にダウンロードするものに近いためです。
+
+- **国際化ライブラリサイズ**: バンドリング、ツリーシェイキング、ミニファイ後の i18n ライブラリのサイズは、空のコンポーネント内のプロバイダー（例：`NextIntlClientProvider`）+ フック（例：`useTranslations`）コードのサイズです。翻訳ファイルの読み込みは含まれません。これにより、コンテンツが入る前にライブラリがどの程度コストがかかるかが分かります。
+
+- **ページごとの JavaScript**: 各ベンチマークルートについて、その訪問時にブラウザが取得するスクリプトの量を、スイート内のページ全体にわたり、またレポートがロールアップする場所のロケール全体にわたって平均化したものです。重いページは遅いページです。
+
+- **他のロケールからのリーク**: 同じページであっても、別の言語であり、監査されたページに誤って読み込まれるコンテンツです。このコンテンツは不要であり、回避する必要があります。（例：`/en/about` ページバンドルの `/fr/about` ページコンテンツ）
+
+- **他のルートからのリーク**: アプリ内の**他の画面**についても同じ考え方です。1 つのページのみを開いたときに、そのコピーが一緒に読み込まれるかどうかです。（例：`/en/contact` ページバンドルの `/en/about` ページコンテンツ）。スコアが高い場合は、分割が弱いか、バンドルが過度に広いことを示唆しています。
+
+- **平均コンポーネントバンドルサイズ**: 一般的な UI コンポーネントは、1 つの巨大なアプリ番号内に隠れるのではなく、**1 つずつ**測定されます。国際化が日常的なコンポーネントを静かに膨張させているかどうかを示します。例えば、コンポーネントが再レンダリングされる場合、メモリからすべてのデータを読み込みます。巨大な JSON をコンポーネントに添付することは、コンポーネントのパフォーマンスを低下させる、使用されていない大量のデータストアに接続するようなものです。
+
+- **言語切り替えレスポンシビティ**: アプリ独自の制御を使用して言語を切り替え、ページが明確に切り替わるまでにかかる時間を計測します。訪問者が気付くこと、ラボの微視的なステップではありません。
+
+- **言語変更後のレンダリング作業**: より狭い追跡です。スイッチが実行中になった後、新しい言語のために、インターフェイスが再描画するのに要した努力がどの程度であるかです。「感じられた」時間とフレームワークコストが異なる場合に役立ちます。
+
+- **初期ページロード時間**: ナビゲーションから、テストしたシナリオについてページが完全に読み込まれたと見なすブラウザまで。コールドスタートを比較するのに適しています。
+
+- **ハイドレーション時間**: アプリが公開している場合、クライアントがサーバー HTML を実際にクリックできるものに変換するのにかかる時間です。テーブルのダッシュ記号は、その実装がこのベンチマークで信頼性の高いハイドレーション数値を提供しなかったことを意味します。
+
 ## GitHubのスター
 
 GitHubのスターは、プロジェクトの普及度、コミュニティの信頼、および長期的な関連性を示す強力な指標です。技術的な品質を直接測定するものではありませんが、どれだけの開発者がプロジェクトを有用だと感じ、その進捗をフォローし、採用する可能性があるかを反映しています。プロジェクトの価値を見積もる際、スターは代替案との勢いの比較を助け、エコシステムの成長に関する洞察を提供します。

package/docs/ja/cli/ci.md

@@ -140,6 +140,28 @@ steps:
     run: npx intlayer ci fill
 ```
 
+## スキャフォルドされた GitHub Actions
+
+`intlayer init` を実行すると、Intlayer はパッケージマネージャー (npm、yarn、pnpm、または bun) を検出し、`.github/workflows/` の下に 2 つの GitHub Actions ワークフローをスキャフォルドします。コマンドはそのパッケージマネージャーに対応します:
+
+- **`intlayer-fill.yml`** — すべてのプルリクエストで、辞書をビルドし `intlayer fill --git-diff --mode complete` を実行して、変更された辞書の欠落している翻訳を生成し、結果を PR ブランチにコミットします。
+- **`intlayer-test.yml`** — すべてのプルリクエストで、辞書をビルドし `intlayer test` を実行し、必要なロケールの翻訳が不足している場合はチェックを失敗させます。
+
+既存のワークフローファイルが上書きされることはありません。スキャフォルディングをスキップするには、以下を実行します:
+
+```bash
+npx intlayer init --no-github-actions
+```
+
+### fill workflowへのAIアクセスの提供
+
+スキャフォルドされた `intlayer-fill.yml` はAIアクセスが必要です。2つのオプションが利用可能です（workflowの `env` ブロックで設定）:
+
+1. **独自のAIプロバイダーキー** — リポジトリ設定（Settings → Secrets and variables → Actions）に `AI_API_KEY` シークレットを追加します。workflowは `--provider`、`--model`、`--api-key` 経由でそれを転送します。
+2. **Intlayer CMSアクセスキー** — `INTLAYER_CLIENT_ID` と `INTLAYER_CLIENT_SECRET` シークレットを追加し、`intlayer.config` の `editor` セクションに接続します。CMSアクセスキーはIntlayer backendを通じてAIアクセスを許可します。
+
+`intlayer-test.yml` workflowはAIアクセスを必要としません。
+
 ## エラーハンドリング
 
 - `INTLAYER_PROJECT_CREDENTIALS`が設定されていない場合、コマンドはエラーで終了します。

package/docs/ja/cli/fill.md

@@ -47,6 +47,14 @@ bun x intlayer fill
 - 既存の翻訳を上書きしないことで、既存の翻訳を保持します。
 - キューシステムを使用してファイル、チャンク、ロケールを並列処理し、速度を向上させます。
 
+## 主なポイント:
+
+- 大規模なJSONファイルをチャンクに分割して、AIモデルのコンテキストウィンドウ制限内に収まるようにします。
+- 出力形式が正しくない場合は翻訳を再試行します。
+- アプリケーション固有とファイル固有のコンテキストを組み込んで、翻訳精度を向上させます。
+- 既存の翻訳を保持し、上書きしません。
+- キューシステムを使用してファイル、チャンク、ロケールを並列処理して、速度を向上させます。
+
 ## エイリアス:
 
 - `npx intlayer dictionaries fill`

package/docs/ja/cli/list_projects.md

@@ -99,24 +99,6 @@ pnpm intlayer projects list
 bun x intlayer projects list
 ```
 
-### 現在のディレクトリ内のプロジェクトを一覧表示:
-
-```bash packageManager="npm"
-npx intlayer projects list --base-dir ./packages
-```
-
-```bash packageManager="yarn"
-yarn intlayer projects list --base-dir ./packages
-```
-
-```bash packageManager="pnpm"
-pnpm intlayer projects list --base-dir ./packages
-```
-
-```bash packageManager="bun"
-bun x intlayer projects list --base-dir ./packages
-```
-
 ### 特定ディレクトリ内のプロジェクトを一覧表示:
 
 ```bash packageManager="npm"