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

package/docs/en-GB/autoFill.md

@@ -28,6 +28,53 @@ history:
 author: aymericzip
 ---
 
+# Fill Content Declaration File Translations
+
+**Autofill content declaration files** in your CI are a way to speed up your development workflow.
+
+## Understanding the behaviour
+
+The `fill` command includes two modes:
+
+- **Complete**: Automatically fill all missing content for each locale and edit the current file, or another file if specified. That is, complete mode will skip the translation of existing content, if already translated.
+- **Review**: Automatically fill **all** content for each locale and generate for a specific file, or another file if specified.
+
+The fill command will process all your locale content declaration files. That is, it will not process your remote content from the CMS. The CMS includes its own translations management.
+If you use plugins such as `@intlayer/sync-json-plugin`, Intlayer will transform the JSON files into locale content declaration files. That is, they will be processed by the `fill` command.
+
+The new generated files include a `filled` instruction as dictionary metadata. This instruction will be used by Intlayer to know if the file has been autofilled or not, and skip this file from being translated again if present.
+
+Intlayer will also consider the following instruction for autofill:
+
+- From your `.content.{ts|js|json}` → `fill` instruction
+- From your configuration file `.intlayer.config.ts` → `dictionary.fill` instruction
+- Will be set to `true` by default otherwise
+
+For per-locale content declaration files, the `true` instruction will be replaced by `./{{fileName}}.fill.content.json`. This is because a per-locale content declaration file cannot receive additional localised content. So it will generate a new file to not overwrite the existing file.
+
+## Default Behavior
+
+By default, `fill` is set to `true` globally, which means Intlayer will automatically fill all content files and edit the file itself. This behaviour can be customised in several ways:
+
+### Global Configuration Options
+
+1. **`fill: true` (default)** - Automatically fill all locales and edit the current file
+2. **`fill: false`** - Disable auto-fill for this content file
+3. **`fill: "./relative/path/to/file"`** - Create/update the specified file without editing the current one by pointing to a relative path resolved based on the location of the current file
+4. **`fill: "/absolute/path/to/file"`** - Create/update the specified file without editing the current one by pointing to a relative path resolved based on the location of base directory (field `baseDir` in the configuration file `.intlayer.config.ts`)
+5. **`fill: "C:\\absolute\path\to\file"`** - Create/update the specified file without editing the current one by pointing to an absolute path resolved based on your operating system
+6. **`fill: { [key in Locales]?: string }`** - Create/update the specified file for each locale
+
+### v7 Behaviour Changes
+
+In v7, the `fill` command behaviour has been updated:
+
+- **`fill: true`** - Rewrites the current file with filled content for all locales
+- **`fill: "path/to/file"`** - Fills the specified file without modifying the current file
+- **`fill: false`** - Disables auto-fill completely
+
+When using a path option to write to another file, the fill mechanism works through a _master-slave_ relationship between content declaration files. The main (master) file serves as the source of truth, and when it's updated, Intlayer will automatically apply those changes to the derived (filled) declaration files specified by the path.
+
 # Autofill Content Declaration File Translations
 
 **Autofill content declaration files** are a way to speed up your development workflow.
@@ -88,6 +135,40 @@ Intlayer will automatically generate the derived declaration file at `src/compon
 
 Afterwards, both declaration files will be merged into a single dictionary, accessible using the standard `useIntlayer("example")` hook (React) / composable (Vue).
 
+## Global Configuration
+
+You can configure the global auto fill configuration in the `intlayer.config.ts` file.
+
+```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: {
+    // Auto-generate missing translations for all dictionaries
+    fill: "./{{fileName}}Filled.content.ts",
+    //
+    // fill: "/messages/{{locale}}/{{key}}/{{fileName}}.content.json",
+    //
+    // fill: true, // auto-generate missing translations for all dictionaries like using "./{{fileName}}.content.json"
+    //
+    // fill: {
+    //   en: "./{{fileName}}.en.content.json",
+    //   fr: "./{{fileName}}.fr.content.json",
+    //   es: "./{{fileName}}.es.content.json",
+    // },
+  },
+};
+
+export default config;
+```
+
+You can still fine‑tune per dictionary using the `fill` field in content files. Intlayer will first consider the per dictionary configuration and then fallback to the global configuration.
+
 ## Autofilled File Format
 
 The recommended format for autofilled declaration files is **JSON**, which helps to avoid formatting constraints. However, Intlayer also supports `.ts`, `.js`, `.mjs`, `.cjs`, and other formats.

package/docs/en-GB/benchmark/solid.md

@@ -118,6 +118,28 @@ We compared **four loading strategies**:
 - **Scoped static**: Keeps code organised (logical separation) without complex extra network requests.
 - **Scoped dynamic**: Best approach for _code splitting_ and performance. Minimises memory by loading only what the current view and active locale need.
 
+### What I measured:
+
+I ran the same multilingual app in a real browser for every stack, then wrote down what actually showed up on the wire and how long things took. Sizes are reported **after normal web compression**, because that is closer to what people download than raw source counts.
+
+- **Internationalization library size**: After bundling, tree-shaking and minification, the size of the i18n library is the size of the providers + hooks/primitives code in an empty component. It does not include the loading of translation files. It answers how expensive the library is before your content enters the picture.
+
+- **JavaScript per page**: For each benchmark route, how much script the browser pulls in for that visit, averaged across the pages in the suite (and across locales where the report rolls them up). Heavy pages are slow pages.
+
+- **Leakage from other locales**: It's the content of the same page but in another language that would be loaded by mistake in the audited page. This content is unnecessary and should be avoided. (e.g. `/fr/about` page content in `/en/about` page bundle)
+
+- **Leakage from other routes**: The same idea for **other screens** in the app: whether their copy is riding along when you only opened one page. (e.g. `/en/about` page content in `/en/contact` page bundle). A high score hints at weak splitting or over-broad bundles.
+
+- **Average component bundle size**: Common UI pieces are measured **one at a time** instead of hiding inside one giant app number. It shows whether internationalization quietly inflates everyday components. For instance, if your component rerenders, it will load all that data from memory. Attaching a giant JSON to any component is like connecting a big store of unused data that will slow down your components' performance.
+
+- **Language switch responsiveness**: I flip the language using the app's own control and time how long it takes until the page has clearly switched, what a visitor would notice, not a lab micro-step.
+
+- **Rendering work after a language change**: A narrower follow-up: how much effort the interface took to repaint for the new language once the switch is in flight. Useful when the "felt" time and the framework cost diverge.
+
+- **Initial page load time**: From navigation to the browser considering the page fully loaded for the scenarios I tested. Good for comparing cold starts.
+
+- **Hydration time**: When the app exposes it, how long the client spends turning server HTML into something you can actually click. A dash in the tables means that implementation did not provide a reliable hydration figure in this benchmark.
+
 ## GitHub STARs
 
 GitHub stars are a strong indicator of a project's popularity, community trust, and long-term relevance. While not a direct measure of technical quality, they reflect how many developers find the project useful, follow its progress, and are likely to adopt it. For estimating the value of a project, stars help compare traction across alternatives and provide insights into ecosystem growth.

package/docs/en-GB/benchmark/svelte.md

@@ -116,6 +116,28 @@ We compared **four loading strategies**:
 - **Scoped static**: Keeps code organised (logical separation) without complex extra network requests.
 - **Scoped dynamic**: Best approach for _code splitting_ and performance. Minimises memory by loading only what the current view and active locale need.
 
+### What I measured:
+
+I ran the same multilingual app in a real browser for every stack, then wrote down what actually showed up on the wire and how long things took. Sizes are reported **after normal web compression**, because that is closer to what people download than raw source counts.
+
+- **Internationalization library size**: After bundling, tree-shaking and minification, the size of the i18n library is the size of the providers + stores code in an empty component. It does not include the loading of translation files. It answers how expensive the library is before your content enters the picture.
+
+- **JavaScript per page**: For each benchmark route, how much script the browser pulls in for that visit, averaged across the pages in the suite (and across locales where the report rolls them up). Heavy pages are slow pages.
+
+- **Leakage from other locales**: It's the content of the same page but in another language that would be loaded by mistake in the audited page. This content is unnecessary and should be avoided. (e.g. `/fr/about` page content in `/en/about` page bundle)
+
+- **Leakage from other routes**: The same idea for **other screens** in the app: whether their copy is riding along when you only opened one page. (e.g. `/en/about` page content in `/en/contact` page bundle). A high score hints at weak splitting or over-broad bundles.
+
+- **Average component bundle size**: Common UI pieces are measured **one at a time** instead of hiding inside one giant app number. It shows whether internationalisation quietly inflates everyday components. For instance, if your component rerenders, it will load all that data from memory. Attaching a giant JSON to any component is like connecting a big store of unused data that will slow down your components' performance.
+
+- **Language switch responsiveness**: I flip the language using the app's own control and time how long it takes until the page has clearly switched, what a visitor would notice, not a lab micro-step.
+
+- **Rendering work after a language change**: A narrower follow-up: how much effort the interface took to repaint for the new language once the switch is in flight. Useful when the "felt" time and the framework cost diverge.
+
+- **Initial page load time**: From navigation to the browser considering the page fully loaded for the scenarios I tested. Good for comparing cold starts.
+
+- **Hydration time**: When the app exposes it, how long the client spends turning server HTML into something you can actually click. A dash in the tables means that implementation did not provide a reliable hydration figure in this benchmark.
+
 ## GitHub STARs
 
 GitHub stars are a strong indicator of a project's popularity, community trust, and long-term relevance. While not a direct measure of technical quality, they reflect how many developers find the project useful, follow its progress, and are likely to adopt it. For estimating the value of a project, stars help compare traction across alternatives and provide insights into ecosystem growth.

package/docs/en-GB/benchmark/tanstack.md

@@ -124,6 +124,28 @@ We compared **four loading strategies**:
 - **Scoped static**: Keeps code organised (logical separation) without complex extra network requests.
 - **Scoped dynamic**: Best approach for _code splitting_ and performance. Minimises memory by loading only what the current view and active locale need.
 
+### What I measured:
+
+I ran the same multilingual app in a real browser for every stack, then wrote down what actually showed up on the wire and how long things took. Sizes are reported **after normal web compression**, because that is closer to what people download than raw source counts.
+
+- **Internationalisation library size**: After bundling, tree-shaking and minification, the size of the i18n library is the size of the providers (e.g. `NextIntlClientProvider`) + hooks (e.g. `useTranslations`) code in an empty component. It does not include the loading of translation files. It answers how expensive the library is before your content enters the picture.
+
+- **JavaScript per page**: For each benchmark route, how much script the browser pulls in for that visit, averaged across the pages in the suite (and across locales where the report rolls them up). Heavy pages are slow pages.
+
+- **Leakage from other locales**: It's the content of the same page but in another language that would be loaded by mistake in the audited page. This content is unnecessary and should be avoided. (e.g. `/fr/about` page content in `/en/about` page bundle)
+
+- **Leakage from other routes**: The same idea for **other screens** in the app: whether their copy is riding along when you only opened one page. (e.g. `/en/about` page content in `/en/contact` page bundle). A high score hints at weak splitting or over-broad bundles.
+
+- **Average component bundle size**: Common UI pieces are measured **one at a time** instead of hiding inside one giant app number. It shows whether internationalisation quietly inflates everyday components. For instance, if your component rerenders, it will load all that data from memory. Attaching a giant JSON to any component is like connecting a big store of unused data that will slow down your components' performance.
+
+- **Language switch responsiveness**: I flip the language using the app's own control and time how long it takes until the page has clearly switched, what a visitor would notice, not a lab micro-step.
+
+- **Rendering work after a language change**: A narrower follow-up: how much effort the interface took to repaint for the new language once the switch is in flight. Useful when the "felt" time and the framework cost diverge.
+
+- **Initial page load time**: From navigation to the browser considering the page fully loaded for the scenarios I tested. Good for comparing cold starts.
+
+- **Hydration time**: When the app exposes it, how long the client spends turning server HTML into something you can actually click. A dash in the tables means that implementation did not provide a reliable hydration figure in this benchmark.
+
 ## GitHub STARs
 
 GitHub stars are a strong indicator of a project's popularity, community trust, and long-term relevance. While not a direct measure of technical quality, they reflect how many developers find the project useful, follow its progress, and are likely to adopt it. For estimating the value of a project, stars help compare traction across alternatives and provide insights into ecosystem growth.

package/docs/en-GB/cli/ci.md

@@ -140,6 +140,28 @@ steps:
     run: npx intlayer ci fill
 ```
 
+## Scaffolded GitHub Actions
+
+When you run `intlayer init`, Intlayer detects your package manager (npm, yarn, pnpm, or bun) and scaffolds two GitHub Actions workflows under `.github/workflows/`, with commands matching that package manager:
+
+- **`intlayer-fill.yml`** — On every pull request, builds the dictionaries and runs `intlayer fill --git-diff --mode complete` to generate missing translations for the changed dictionaries, then commits the result back to the PR branch.
+- **`intlayer-test.yml`** — On every pull request, builds the dictionaries and runs `intlayer test`, failing the check when required locales are missing translations.
+
+Existing workflow files are never overwritten. To skip scaffolding entirely, run:
+
+```bash
+npx intlayer init --no-github-actions
+```
+
+### Providing AI access to the fill workflow
+
+The scaffolded `intlayer-fill.yml` requires AI access. Two options are available (configured in the workflow's `env` block):
+
+1. **Your own AI provider key** — Add an `AI_API_KEY` secret in your repository settings (Settings → Secrets and variables → Actions). The workflow forwards it via `--provider`, `--model`, and `--api-key`.
+2. **Intlayer CMS access keys** — Add `INTLAYER_CLIENT_ID` and `INTLAYER_CLIENT_SECRET` secrets and wire them into your `intlayer.config` `editor` section. CMS access keys grant AI access through the Intlayer backend.
+
+The `intlayer-test.yml` workflow does not require any AI access.
+
 ## Error Handling
 
 - If `INTLAYER_PROJECT_CREDENTIALS` is not set, the command will exit with an error.

package/docs/en-GB/cli/doc-review.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-06-17
 title: Review Document
 description: Learn how to review documentation files for quality, consistency, and completeness across different locales.
 keywords:
@@ -15,6 +15,10 @@ slugs:
   - concept
   - cli
   - doc-review
+history:
+  - version: 9.0.0
+    date: 2026-06-17
+    changes: "Add --log option"
 author: aymericzip
 ---
 
@@ -55,8 +59,110 @@ For most use cases,
 
 ## Arguments:
 
-The `doc review` command accepts the same arguments as `doc translate`, allowing you to review specific documentation files and apply quality checks.
+**File list options:**
 
-If you have activated one of the git options, the command will only review the parts of the files that are being changed. The script will process by chunking the file and reviewing each chunk. If there are no changes in the chunk, the script will skip it to speed up the review process and limit the AI Provider API cost.
+- **`--doc-pattern [docPattern...]`**: Glob patterns to match documentation files to review.
 
-For a complete list of arguments, see the [Translate Document](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en-GB/cli/doc-translate.md) command documentation.
+  > Example: `npx intlayer doc review --doc-pattern "docs/**/*.md" "src/**/*.mdx"`
+
+- **`--excluded-glob-pattern [excludedGlobPattern...]`**: Glob patterns to exclude from review.
+
+  > Example: `npx intlayer doc review --excluded-glob-pattern "docs/internal/**"`
+
+- **`--skip-if-modified-before [skipIfModifiedBefore]`**: Skip the file if it has been modified before the specified time.
+  - Can be an absolute time such as "2025-12-05" (string or Date)
+  - Can be a relative time in ms `1 * 60 * 60 * 1000` (1 hour)
+  - This option checks the update time of the file using the `fs.stat` method. Therefore, it could be affected by Git or other tools that modify the file.
+
+  > Example: `npx intlayer doc review --skip-if-modified-before "2025-12-05"`
+
+- **`--skip-if-modified-after [skipIfModifiedAfter]`**: Skip the file if it has been modified within the specified time.
+  - Can be an absolute time such as "2025-12-05" (string or Date)
+  - Can be a relative time in ms `1 * 60 * 60 * 1000` (1 hour)
+  - This option checks the update time of the file using the `fs.stat` method. Therefore, it could be affected by Git or other tools that modify the file.
+
+  > Example: `npx intlayer doc review --skip-if-modified-after "2025-12-05"`
+
+- **`--skip-if-exists`**: Skip the file if it already exists.
+
+  > Example: `npx intlayer doc review --skip-if-exists`
+
+**Review mode options:**
+
+- **`--log`**: Log-only mode. Do not translate with AI; instead log the blocks that need attention (with line numbers and content) for the base and target locales, to help another agent generate the translations.
+
+  > Example: `npx intlayer doc review --log`
+
+**Entry output options:**
+
+- **`--locales [locales...]`**: Target locales to review documentation for.
+
+  > Example: `npx intlayer doc review --locales fr es de`
+
+- **`--base-locale [baseLocale]`**: Source locale (base document) to compare with.
+
+  > Example: `npx intlayer doc review --base-locale en`
+
+**File processing options:**
+
+- **`--nb-simultaneous-file-processed [nbSimultaneousFileProcessed]`**: Number of files to process simultaneously for review.
+
+  > Example: `npx intlayer doc review --nb-simultaneous-file-processed 5`
+
+**AI options:**
+
+- **`--model [model]`**: The AI model to use for review (e.g., `gpt-3.5-turbo`).
+- **`--provider [provider]`**: The AI provider to use for review.
+- **`--temperature [temperature]`**: Temperature setting for the AI model.
+- **`--api-key [apiKey]`**: Provide your own API key for the AI service.
+- **`--application-context [applicationContext]`**: Provide additional context for the AI review.
+- **`--data-serialization [dataSerialization]`**: The data serialization format to use for the AI features of Intlayer. Options: `json` (standard, reliable), `toon` (fewer tokens, less consistent).
+- **`--custom-prompt [prompt]`**: Customise the base prompt used for review. (Note: For most use cases, the `--custom-instructions` option is recommended instead.)
+
+  > Example: `npx intlayer doc review --model deepseek-chat --provider deepseek --temperature 0.5 --api-key sk-1234567890 --application-context "My application is a cat store"`
+
+**Environment variables options:**
+
+- **`--env`**: Specify the environment (e.g., `development`, `production`).
+- **`--env-file [envFile]`**: Provide a custom environment file to load variables from.
+- **`--base-dir`**: Specify the base directory for the project.
+- **`--no-cache`**: Disable the cache.
+
+  > Example: `npx intlayer doc review --base-dir ./docs --env-file .env.production.local`
+
+**Log options:**
+
+- **`--verbose`**: Enable verbose logging for debugging. (defaults to true when using CLI)
+
+  > Example: `npx intlayer doc review --verbose`
+
+**Custom instructions options:**
+
+- **`--custom-instructions [customInstructions]`**: Custom instructions added to the prompt. Useful for applying specific rules regarding formatting, URL translation, etc.
+
+  > Example: `npx intlayer doc review --custom-instructions "Avoid translating URLs, and keep the markdown format"`
+
+  > Example: `npx intlayer doc review --custom-instructions "$(cat ./instructions.md)"`
+
+**Git options:**
+
+- **`--git-diff`**: Only run on files that include changes from base (default `origin/main`) to current branch (default: `HEAD`).
+- **`--git-diff-base`**: Specify the base reference for git diff (default `origin/main`).
+- **`--git-diff-current`**: Specify the current reference for git diff (default: `HEAD`).
+- **`--uncommitted`**: Include uncommitted changes.
+- **`--unpushed`**: Include unpushed changes.
+- **`--untracked`**: Include untracked files.
+
+  > Example: `npx intlayer doc review --git-diff --git-diff-base origin/main --git-diff-current HEAD`
+
+  > Example: `npx intlayer doc review --uncommitted --unpushed --untracked`
+
+> Note that the output file path will be determined by replacing the following patterns:
+>
+> - `/{{baseLocale}}/` with `/{{locale}}/` (Unix)
+> - `\{{baseLocale}}\` with `\{{locale}}\` (Windows)
+> - `_{{baseLocale}}.` with `_{{locale}}.`
+> - `{{baseLocale}}_` with `{{locale}}_`
+> - `.{{baseLocaleName}}.` with `.{{localeName}}.`
+>
+> If the pattern is not found, the output file will add `.{{locale}}` to the file extension. For example, `./my/file.md` will be reviewed and updated to `./my/file.fr.md` for the French locale.

package/docs/en-GB/cli/fill.md

@@ -47,6 +47,14 @@ Key Points:
 - Preserves existing translations by not overwriting them.
 - Processes files, chunks, and locales in parallel using a queue system to increase speed.
 
+## Key Points:
+
+- Splits large JSON files into chunks to stay within the AI model's context window limits.
+- Retries translation if the output format is incorrect.
+- Incorporates application and file-specific context for improved translation accuracy.
+- Preserves existing translations by not overwriting them.
+- Processes files, chunks, and locales in parallel using a queue system to increase speed.
+
 ## Aliases:
 
 - `npx intlayer dictionaries fill`

package/docs/en-GB/cli/index.md

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

package/docs/en-GB/cli/login.md

@@ -80,42 +80,6 @@ bun x intlayer login --cms-url https://intlayer.org
 
 You can also use common configuration options:
 
-- `--env-file <path>`: Path to the environment file
-- `-e, --env <env>`: Execution environment
-- `--base-dir <dir>`: Base directory of the project
-- `--verbose`: Enable detailed output (default: true)
-- `--prefix <prefix>`: Prefix for logs
-
-## How It Works
-
-1. **Local server start**: The command starts a local HTTP server on a random port to receive credentials from the CMS
-
-Specify the URL of the Intlayer CMS to connect to for authentication.
-
-- **Type**: `string`
-- **Default**: The value configured in `intlayer.config.*` or `https://intlayer.org`
-- **Example**:
-
-```bash packageManager="npm"
-npx intlayer login --cms-url https://intlayer.org
-```
-
-```bash packageManager="yarn"
-yarn intlayer login --cms-url https://intlayer.org
-```
-
-```bash packageManager="pnpm"
-pnpm intlayer login --cms-url https://intlayer.org
-```
-
-```bash packageManager="bun"
-bun x intlayer login --cms-url https://intlayer.org
-```
-
-### Configuration Options
-
-You can also use common configuration options:
-
 - `--env-file <path>`: Path to the environment file
 - `-e, --env <env>`: Execution environment
 - `--base-dir <dir>`: Base directory of the project

package/docs/en-GB/cli/scan.md

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

package/docs/en-GB/cli/test.md

@@ -98,40 +98,4 @@ pnpm intlayer content test --verbose
 bun x intlayer content test --verbose
 ```
 
-The output helps you quickly identify which translations need to be completed to ensure your application works correctly across all configured locales.
-
-> Example: `npx intlayer content test --base-dir ./src --env-file .env.production.local`
-
-- **`--no-cache`**: Disable the cache.
-
-  > Example: `npx intlayer build --no-cache`
-
-**Preparation options:**
-
-- **`--build`**: Build the dictionaries before pushing to ensure the content is up to date. True will force the build, false will skip the build, undefined will allow using the cache of the build.
-
-**Log options:**
-
-- **`--verbose`**: Enable verbose logging for debugging. (default to true using CLI)
-
-  > Example: `npx intlayer content test --verbose`
-
-## Example:
-
-```bash packageManager="npm"
-npx intlayer content test --verbose
-```
-
-```bash packageManager="yarn"
-yarn intlayer content test --verbose
-```
-
-```bash packageManager="pnpm"
-pnpm intlayer content test --verbose
-```
-
-```bash packageManager="bun"
-bun x intlayer content test --verbose
-```
-
 The output helps you quickly identify which translations need to be completed to ensure your application works properly across all configured locales.

package/docs/en-GB/compat/i18n-js.md

@@ -0,0 +1,44 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migrate from i18n-js to Intlayer"
+description: "Learn how to migrate your application from i18n-js to Intlayer using the compat adapter."
+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
+---
+
+# Migrate from i18n-js to Intlayer
+
+Transitioning from the `i18n-js` library to Intlayer is a highly optimised migration designed to offload large translations configurations into Intlayer's structured file resolution system.
+
+## What to do
+
+Execute the following setup command in your repository:
+
+```bash
+npx intlayer init
+```
+
+With `intlayer.config.ts` prepared, you can add Intlayer's alias to your bundler configuration so that any imports of `i18n-js` target the compat package `@intlayer/i18n-js`.
+
+## What it does under the hood
+
+`i18n-js` accesses namespaces through expressions like `i18n.t('scope.key', {name})` along with locale fallbacks and specific plural mappings.
+
+Under the hood:
+
+- **Interpolation:** The compat adapter easily parses `%{name}` mappings into your targeted runtime dictionary value.
+- **Pluralisation:** Replaces `one/other` subkeys and maps them against Intlayer's powerful underlying plural mechanisms (`Intl.PluralRules`), abstracting away manual mappings.
+- **Locales:** Instead of loading monolithic language payloads at bootstrap, dictionaries are served up optimally based on the current context setup via the native Intlayer configuration.

package/docs/en-GB/compat/i18next.md

@@ -0,0 +1,59 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migrate from i18next to Intlayer"
+description: "Learn how to migrate your Vanilla JS/TS application from i18next to Intlayer using the compat adapter."
+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
+---
+
+# Migrate from i18next to Intlayer
+
+For a detailed step-by-step tutorial, please see our full [i18next Migration Guide](../migration_from_i18next_to_intlayer.md).
+
+Intlayer perfectly replicates the core runtime characteristics of `i18next`. By utilising the compat package, your Vanilla applications or internal modules can continue to leverage familiar syntax.
+
+## What to do
+
+To begin, initialise Intlayer in your project:
+
+```bash
+npx intlayer init
+```
+
+If you are using Vite, include the Intlayer plugin to route imports to `@intlayer/i18next`:
+
+```typescript fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import { i18nextVitePlugin } from "@intlayer/i18next/plugin";
+
+export default defineConfig({
+  plugins: [i18nextVitePlugin()],
+});
+```
+
+## What it does under the hood
+
+The `i18nextVitePlugin` aliases `i18next` imports to `@intlayer/i18next`, avoiding bundle bloat from JSON file inclusions.
+
+Under the hood:
+
+- **Instance configuration:** `createInstance` correctly parses and applies namespace fallbacks while leveraging Intlayer's compilation pipeline for dictionary retrieval.
+- **Interpolation:** Native support for `{{name}}` replacements and `$t(key)` nesting recursively.
+- **Context & Plurals:** Identifies and resolves suffix formats like `key_male` and `key_one`/`key_other` evaluating against standard `Intl.PluralRules`.
+- **Return objects:** The `returnObjects: true` mode safely extracts trees from Intlayer dictionaries.

package/docs/en-GB/compat/index.md

@@ -0,0 +1,51 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Intlayer Compat Adapters"
+description: "Migrate your existing i18n solution to Intlayer with zero friction using compat adapters."
+keywords:
+  - compat
+  - migration
+  - internationalisation
+  - i18n
+  - Intlayer
+slugs:
+  - doc
+  - compatibility
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Intlayer Compat Adapters
+
+Migrating a large application to a new internationalisation library can be daunting. To ease this transition, Intlayer provides **compat adapters** for the most popular i18n libraries in the ecosystem.
+
+These adapter packages expose the **exact same public API** as your existing i18n libraries, but delegate all translation work to Intlayer at runtime.
+
+## How it works
+
+When you use a compat adapter, you do not need to rewrite your application's imports or change how you use your translation hooks and components. Instead, Intlayer's bundler plugins automatically alias your existing imports to the Intlayer compat packages.
+
+For example, a developer replaces `import { useTranslation } from 'react-i18next'` with `import { useTranslation } from '@intlayer/react-i18next'` (done automatically via the bundler plugin), and the app keeps working with translations now served from Intlayer dictionaries. Keys are also typed against your Intlayer dictionaries!
+
+## Available Compat Adapters
+
+Choose your existing library below to see how to migrate seamlessly:
+
+- [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)