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

package/docs/es/self_hosting.md

@@ -0,0 +1,349 @@
+---
+createdAt: 2026-06-30
+updatedAt: 2026-06-30
+title: Autoalojamiento de Intlayer
+description: Ejecuta una instancia completa de Intlayer en tu propia infraestructura con un solo comando. No se requiere una cuenta de Intlayer Cloud.
+keywords:
+  - Self-Hosting
+  - Docker
+  - Docker Compose
+  - Intlayer
+  - CMS
+  - Installation
+  - Infrastructure
+slugs:
+  - doc
+  - self-hosting
+author: aymericzip
+---
+
+# Autoalojamiento de Intlayer
+
+Intlayer puede ejecutarse completamente en tu propia infraestructura, sin necesidad de una cuenta de Intlayer Cloud. Un solo comando inicia una pila lista para producción:
+
+```sh
+curl -fsSL https://intlayer.org/install.sh | sh
+```
+
+El instalador descarga un `docker-compose.yml` y un `.env`, autogenera los secretos necesarios e inicia todos los contenedores con `docker compose up -d`.
+
+## Tabla de Contenidos
+
+<TOC/>
+
+---
+
+## Arquitectura
+
+```
+                ┌─────────────────────────────┐
+ navegador ──────▶ │  app  (TanStack Start)  :3000│ ──┐
+                └─────────────────────────────┘   │ VITE_BACKEND_URL
+                ┌─────────────────────────────┐   │
+                │  backend (Fastify/Bun)  :3100│ ◀─┘
+                └──────────────┬──────────────┘
+          ┌──────────┬─────────┼──────────┬───────────┐
+          ▼          ▼         ▼          ▼           ▼
+     mongo:27017  redis:6379  minio:9000  mailpit:1025  Chromium
+     (RS de 1 nodo)             (API de S3)     (SMTP)        (en-imagen)
+                             minio:9001   mailpit:8025
+                             (consola)    (interfaz web)
+```
+
+Chromium (utilizado para la generación de capturas de pantalla de Puppeteer) se incluye dentro de la imagen del backend, no se necesita un contenedor separado.
+
+---
+
+## Requisitos previos
+
+- **Docker** ≥ 24 y **Docker Compose** ≥ v2. Si falta alguno, el instalador imprimirá el enlace de instalación y saldrá.
+- Puertos `3000`, `3100`, `8025`, `9000` y `9001` disponibles en el host.
+- Un host Linux o macOS (o WSL2 en Windows).
+
+---
+
+## Inicio rápido
+
+```sh
+curl -fsSL https://intlayer.org/install.sh | sh
+```
+
+Lo que hace el instalador:
+
+1.  Verifica que `docker` y `docker compose` estén presentes.
+2.  Descarga `docker-compose.yml` y `.env.example` en `./intlayer/`.
+3.  Si no existe un `.env`, copia el ejemplo y genera secretos aleatorios para `BETTER_AUTH_SECRET`, `S3_ACCESS_KEY_ID` y `S3_SECRET_ACCESS_KEY` a través de `openssl rand`.
+4.  Ejecuta `docker compose pull` + `docker compose up -d`.
+5.  Imprime las URLs: dashboard `:3000`, API `:3100`, interfaz de usuario de correo electrónico `:8025`, consola de MinIO `:9001`.
+
+Una vez que la pila esté en funcionamiento, abre **http://localhost:3000** y crea tu primera cuenta.
+
+---
+
+## Servicios
+
+| Servicio    | Imagen                                     | Puerto(s) del host                   | Propósito                                                                        |
+| :---------- | :----------------------------------------- | :----------------------------------- | :------------------------------------------------------------------------------- |
+| **app**     | construido desde `apps/app/Dockerfile`     | `3000`                               | Dashboard de TanStack Start (UI del CMS)                                         |
+| **backend** | construido desde `apps/backend/Dockerfile` | `3100`                               | API REST de Fastify (endpoint `/health`)                                         |
+| **mongo**   | `mongo:7`                                  | interno                              | Conjunto de réplicas de un solo nodo (`rs0`)                                     |
+| **redis**   | `redis:7-alpine`                           | interno                              | Colas de trabajos (BullMQ) y almacenamiento en caché (ioredis)                   |
+| **minio**   | `minio/minio`                              | `9000` (S3), `9001` (consola)        | Almacenamiento de objetos compatible con S3 para avatares y capturas de pantalla |
+| **mailpit** | `axllent/mailpit`                          | `1025` (SMTP), `8025` (interfaz web) | Receptor local de correos electrónicos transaccionales                           |
+
+Los puertos internos (mongo, redis) no se exponen al host por defecto.
+
+> El puerto `9000` de MinIO debe ser accesible desde el navegador porque los activos cargados (avatares, capturas de pantalla) se cargan directamente desde `S3_PUBLIC_URL=http://localhost:9000/intlayer`.
+
+---
+
+## Variables de entorno
+
+El instalador genera un archivo `.env` listo para usar. La siguiente tabla describe cada variable.
+
+### Requeridas (autogeneradas o solicitadas)
+
+| Variable               | Ejemplo                                         | Descripción                                                         |
+| :--------------------- | :---------------------------------------------- | :------------------------------------------------------------------ |
+| `NODE_ENV`             | `production`                                    | Entorno de ejecución                                                |
+| `PORT`                 | `3100`                                          | Puerto de escucha del backend                                       |
+| `BACKEND_URL`          | `http://localhost:3100`                         | URL pública de la API del backend                                   |
+| `APP_URL`              | `http://localhost:3000`                         | URL pública del dashboard                                           |
+| `DOMAIN`               | `localhost`                                     | Dominio de la cookie                                                |
+| `MONGODB_URI`          | `mongodb://mongo:27017/intlayer?replicaSet=rs0` | URI de conexión completa de MongoDB                                 |
+| `REDIS_URL`            | `redis://redis:6379`                            | URL de conexión de Redis                                            |
+| `BETTER_AUTH_SECRET`   | _(generado)_                                    | Secreto de 32 bytes para la firma de sesiones                       |
+| `MAIL_PROVIDER`        | `smtp`                                          | Transporte de correo: `smtp` o `resend`                             |
+| `MAIL_SMTP_HOST`       | `mailpit`                                       | Nombre de host SMTP (nombre del contenedor de Mailpit)              |
+| `MAIL_SMTP_PORT`       | `1025`                                          | Puerto SMTP                                                         |
+| `MAIL_FROM`            | `Intlayer <no-reply@localhost>`                 | Dirección del remitente                                             |
+| `S3_ENDPOINT`          | `http://minio:9000`                             | Endpoint compatible con S3                                          |
+| `S3_PUBLIC_URL`        | `http://localhost:9000/intlayer`                | URL pública para la carga de activos del navegador                  |
+| `S3_BUCKET_NAME`       | `intlayer`                                      | Nombre del bucket                                                   |
+| `S3_ACCESS_KEY_ID`     | _(generado)_                                    | Clave de acceso de MinIO                                            |
+| `S3_SECRET_ACCESS_KEY` | _(generado)_                                    | Clave secreta de MinIO                                              |
+| `VITE_BACKEND_URL`     | `http://localhost:3100`                         | URL del backend integrada en el dashboard en tiempo de construcción |
+| `VITE_DOMAIN`          | `localhost`                                     | Dominio integrado en el dashboard en tiempo de construcción         |
+
+### Opcionales (las características se degradan elegantemente cuando están ausentes)
+
+| Variable                                                 | Característica                                                                          |
+| :------------------------------------------------------- | :-------------------------------------------------------------------------------------- |
+| `OPENAI_API_KEY`                                         | Traducción asistida por IA y auditoría de contenido                                     |
+| `STRIPE_SECRET_KEY`, `STRIPE_WEBHOOK_SECRET`, `STRIPE_*` | Gestión de facturación y suscripciones                                                  |
+| `RESEND_API_KEY`                                         | Correo electrónico transaccional a través de Resend (anula Mailpit cuando se configura) |
+| `GITHUB_CLIENT_ID`, `GITHUB_CLIENT_SECRET`               | Inicio de sesión GitHub OAuth                                                           |
+| `GOOGLE_CLIENT_ID`, `GOOGLE_CLIENT_SECRET`               | Inicio de sesión Google OAuth                                                           |
+| `GITLAB_CLIENT_ID`, `GITLAB_CLIENT_SECRET`               | Inicio de sesión GitLab OAuth                                                           |
+| `MICROSOFT_CLIENT_ID`, `MICROSOFT_CLIENT_SECRET`         | Inicio de sesión Microsoft OAuth                                                        |
+| `LINKEDIN_CLIENT_ID`, `LINKEDIN_CLIENT_SECRET`           | Inicio de sesión LinkedIn OAuth                                                         |
+| `ATLASSIAN_CLIENT_ID`, `ATLASSIAN_CLIENT_SECRET`         | Inicio de sesión Atlassian OAuth                                                        |
+
+---
+
+## Conectando tu proyecto Intlayer
+
+Una vez que la pila esté en funcionamiento, apunta tu proyecto al backend y dashboard autoalojados en lugar de `intlayer.org`.
+
+### Configuración del proyecto
+
+```typescript fileName="intlayer.config.ts" codeFormat={["typescript", "esm", "commonjs"]}
+import type { IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  editor: {
+    clientId: process.env.INTLAYER_CLIENT_ID,
+    clientSecret: process.env.INTLAYER_CLIENT_SECRET,
+
+    /**
+     * URL del dashboard CMS autoalojado.
+     * Por defecto: https://app.intlayer.org
+     */
+    cmsURL: process.env.INTLAYER_CMS_URL, // e.g. http://localhost:3000
+
+    /**
+     * URL de la API del backend autoalojado.
+     * Por defecto: https://back.intlayer.org
+     */
+    backendURL: process.env.INTLAYER_BACKEND_URL, // e.g. http://localhost:3100
+  },
+};
+
+export default config;
+```
+
+Establece las variables de entorno en el `.env` de tu proyecto:
+
+```sh
+INTLAYER_CMS_URL=http://localhost:3000
+INTLAYER_BACKEND_URL=http://localhost:3100
+INTLAYER_CLIENT_ID=<your-client-id>
+INTLAYER_CLIENT_SECRET=<your-client-secret>
+```
+
+Crea credenciales de acceso en tu dashboard autoalojado en **Proyectos → Claves de acceso** en `http://localhost:3000/projects`.
+
+### SDK de `@intlayer/api`
+
+Al usar el SDK de `@intlayer/api` programáticamente, pasa `backendURL` explícitamente:
+
+```typescript fileName="cms.ts" codeFormat="typescript"
+import { createIntlayerCMS } from "@intlayer/api";
+import { dictionaryEndpoint } from "@intlayer/api/dictionary";
+
+const cms = createIntlayerCMS({
+  editor: {
+    clientId: process.env.INTLAYER_CLIENT_ID,
+    clientSecret: process.env.INTLAYER_CLIENT_SECRET,
+    backendURL: process.env.INTLAYER_BACKEND_URL, // http://localhost:3100
+  },
+});
+
+const { data: dictionaries } = await dictionaryEndpoint(cms).getDictionaries();
+```
+
+---
+
+## Actualización
+
+Volver a ejecutar el instalador en un despliegue existente realiza una actualización continua:
+
+```sh
+curl -fsSL https://intlayer.org/install.sh | sh
+```
+
+Esto descarga las últimas imágenes y reinicia los contenedores con `docker compose pull && docker compose up -d`. Los volúmenes existentes (`mongo-data`, `redis-data`, `minio-data`) se conservan, sin pérdida de datos.
+
+Para actualizar manualmente desde el directorio `./intlayer/`:
+
+```sh
+docker compose pull
+docker compose up -d
+```
+
+---
+
+## Copia de seguridad y restauración
+
+Todos los datos persistentes residen en tres volúmenes de Docker con nombre.
+
+### Copia de seguridad
+
+```sh
+docker run --rm \
+  -v intlayer_mongo-data:/data \
+  -v "$(pwd)":/backup \
+  busybox tar czf /backup/mongo-data.tar.gz /data
+
+docker run --rm \
+  -v intlayer_redis-data:/data \
+  -v "$(pwd)":/backup \
+  busybox tar czf /backup/redis-data.tar.gz /data
+
+docker run --rm \
+  -v intlayer_minio-data:/data \
+  -v "$(pwd)":/backup \
+  busybox tar czf /backup/minio-data.tar.gz /data
+```
+
+### Restauración
+
+```sh
+docker run --rm \
+  -v intlayer_mongo-data:/data \
+  -v "$(pwd)":/backup \
+  busybox tar xzf /backup/mongo-data.tar.gz -C /
+
+# Repetir para redis-data y minio-data
+```
+
+---
+
+## Uso de un proxy inverso (Nginx / Caddy)
+
+Para despliegues de producción, coloca un proxy inverso delante de los contenedores de la aplicación y del backend en lugar de exponerlos directamente.
+
+### Ejemplo de Nginx
+
+```nginx
+server {
+    listen 80;
+    server_name cms.example.com;
+
+    location / {
+        proxy_pass http://localhost:3000;
+        proxy_set_header Host $host;
+        proxy_set_header X-Real-IP $remote_addr;
+    }
+}
+
+server {
+    listen 80;
+    server_name api.example.com;
+
+    location / {
+        proxy_pass http://localhost:3100;
+        proxy_set_header Host $host;
+        proxy_set_header X-Real-IP $remote_addr;
+    }
+}
+```
+
+Actualiza las siguientes variables `.env` para que coincidan con tus dominios públicos:
+
+```sh
+BACKEND_URL=https://api.example.com
+APP_URL=https://cms.example.com
+DOMAIN=example.com
+VITE_BACKEND_URL=https://api.example.com
+VITE_DOMAIN=example.com
+```
+
+> Las variables `VITE_*` se integran en la imagen del dashboard en el momento de la construcción. Si las cambias después de que se construya la imagen, necesitas reconstruir la imagen de la `app` (`docker compose build app`) o usar la inyección de configuración en tiempo de ejecución.
+
+---
+
+## Solución de problemas
+
+### Reinicios del backend en bucle al inicio
+
+MongoDB y Redis deben estar saludables antes de que el backend se inicie. El archivo compose utiliza `depends_on` con `condition: service_healthy`. Si ves reinicios repetidos del backend, verifica que los healthchecks de `mongo` y `redis` pasen:
+
+```sh
+docker compose ps
+docker compose logs mongo
+docker compose logs redis
+```
+
+### El dashboard no puede conectar con la API
+
+Verifica que `VITE_BACKEND_URL` coincida con la URL donde el backend es accesible desde el **navegador** (no desde la red de Docker). Si cambiaste el puerto del backend o añadiste un proxy inverso, reconstruye la imagen del dashboard:
+
+```sh
+docker compose build app
+docker compose up -d app
+```
+
+### El correo electrónico no se envía
+
+Por defecto, todos los correos electrónicos salientes son capturados por Mailpit. Abre `http://localhost:8025` para ver los mensajes enviados. Para enviar correos electrónicos reales, establece `MAIL_PROVIDER=resend` y `RESEND_API_KEY=<tu-clave>` en `.env`, luego reinicia el backend:
+
+```sh
+docker compose restart backend
+```
+
+### Falta el bucket de MinIO
+
+Si el servicio de un solo uso `minio-init` no se ejecutó (o se ejecutó antes de que MinIO estuviera listo), crea el bucket manualmente:
+
+```sh
+docker compose run --rm minio-init
+```
+
+---
+
+## Enlaces útiles
+
+- [Documentación del CMS de Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/docs/es/intlayer_CMS.md)
+- [Referencia de configuración](https://github.com/aymericzip/intlayer/blob/main/docs/docs/es/configuration.md)
+- [SDK del CMS — `@intlayer/api`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/es/intlayer_CMS.md#programmatic-access-con-el-sdk-intlayerapi)

package/docs/fr/CI_CD.md

@@ -26,6 +26,10 @@ author: aymericzip
 
 Intlayer permet la génération automatique des traductions pour vos fichiers de déclaration de contenu. Plusieurs méthodes existent selon votre flux de travail.
 
+## Table des matières
+
+<TOC/>
+
 ## Utilisation du CMS
 
 Avec Intlayer, vous pouvez adopter un flux de travail où une seule locale est déclarée localement, tandis que toutes les traductions sont gérées à distance via le CMS. Cela permet de détacher complètement le contenu et les traductions de la base de code, offrant plus de flexibilité aux éditeurs de contenu et permettant le rechargement dynamique du contenu (pas besoin de reconstruire l'application pour appliquer les modifications).

package/docs/fr/autoFill.md

@@ -28,6 +28,53 @@ history:
 author: aymericzip
 ---
 
+# Remplir les fichiers de déclaration de contenu traduits
+
+**L'autofill des fichiers de déclaration de contenu** dans votre CI est un moyen d'accélérer votre flux de développement.
+
+## Comprendre le comportement
+
+La commande `fill` inclut deux modes :
+
+- **Complete** : Remplit automatiquement tout le contenu manquant pour chaque locale et modifie le fichier actuel, ou un autre fichier s'il est spécifié. C'est-à-dire que le mode complete ignorera la traduction du contenu existant, s'il est déjà traduit.
+- **Review** : Remplit automatiquement **tout** le contenu pour chaque locale et génère pour un fichier spécifique, ou un autre fichier s'il est spécifié.
+
+La commande will traitera tous vos fichiers de déclaration de contenu locale. C'est-à-dire qu'elle ne traitera pas votre contenu distant du CMS. Le CMS inclut sa propre gestion des traductions.
+Si vous utilisez des plugins comme `@intlayer/sync-json-plugin`, Intlayer transformera les fichiers JSON en fichiers de déclaration de contenu locale. C'est-à-dire qu'ils seront traités par la commande `fill`.
+
+Les fichiers nouvellement générés incluent une instruction `filled` comme métadonnées de dictionnaire. Cette instruction sera utilisée par Intlayer pour savoir si le fichier a été rempli automatiquement ou non, et ignorer ce fichier d'une traduction supplémentaire s'il est présent.
+
+Intlayer considérera également l'instruction suivante pour le remplissage automatique :
+
+- De votre `.content.{ts|js|json}` → instruction `fill`
+- De votre fichier de configuration `.intlayer.config.ts` → instruction `dictionary.fill`
+- Sera défini à `true` par défaut autrement
+
+Pour les fichiers de déclaration de contenu par locale, l'instruction `true` sera remplacée par `./{{fileName}}.fill.content.json`. C'est parce qu'un fichier de déclaration de contenu par locale ne peut pas recevoir de contenu localisé supplémentaire. Donc il générera un nouveau fichier pour ne pas écraser le fichier existant.
+
+## Comportement par défaut
+
+Par défaut, `fill` est défini sur `true` globalement, ce qui signifie qu'Intlayer remplira automatiquement tous les fichiers de contenu et modifiera le fichier lui-même. Ce comportement peut être personnalisé de plusieurs façons :
+
+### Options de Configuration Globale
+
+1. **`fill: true` (par défaut)** - Remplir automatiquement toutes les locales et éditer le fichier courant
+2. **`fill: false`** - Désactiver le remplissage automatique pour ce fichier de contenu
+3. **`fill: "./relative/path/to/file"`** - Créer/mettre à jour le fichier spécifié sans éditer le fichier courant en pointant vers un chemin relatif résolu en fonction de l'emplacement du fichier courant
+4. **`fill: "/absolute/path/to/file"`** - Créer/mettre à jour le fichier spécifié sans éditer le fichier courant en pointant vers un chemin relatif résolu en fonction de l'emplacement du répertoire de base (champ `baseDir` dans le fichier de configuration `.intlayer.config.ts`)
+5. **`fill: "C:\\absolute\path\to\file"`** - Créer/mettre à jour le fichier spécifié sans éditer le fichier courant en pointant vers un chemin absolu résolu en fonction de votre système d'exploitation
+6. **`fill: { [key in Locales]?: string }`** - Créer/mettre à jour le fichier spécifié pour chaque locale
+
+### Changements de comportement v7
+
+Dans v7, le comportement de la commande `fill` a été mis à jour :
+
+- **`fill: true`** - Réécrit le fichier courant avec le contenu rempli pour toutes les locales
+- **`fill: "path/to/file"`** - Remplit le fichier spécifié sans modifier le fichier courant
+- **`fill: false`** - Désactive complètement le remplissage automatique
+
+Lors de l'utilisation d'une option de chemin pour écrire dans un autre fichier, le mécanisme de remplissage fonctionne via une relation _maître-esclave_ entre les fichiers de déclaration de contenu. Le fichier principal (maître) sert de source de vérité, et lorsqu'il est mis à jour, Intlayer applique automatiquement ces modifications aux fichiers de déclaration dérivés (remplis) spécifiés par le chemin.
+
 # Traductions des fichiers de déclaration de contenu avec remplissage automatique
 
 **Les fichiers de déclaration de contenu avec remplissage automatique** sont un moyen d'accélérer votre flux de travail de développement.
@@ -88,6 +135,40 @@ Intlayer générera automatiquement le fichier de déclaration dérivé à `src/
 
 Ensuite, les deux fichiers de déclaration seront fusionnés en un seul dictionnaire, accessible via le hook standard `useIntlayer("example")` (react) / composable (vue).
 
+## Configuration globale
+
+Vous pouvez configurer la configuration de remplissage automatique globale dans le fichier `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: {
+    // Générer automatiquement les traductions manquantes pour tous les dictionnaires
+    fill: "./{{fileName}}Filled.content.ts",
+    //
+    // fill: "/messages/{{locale}}/{{key}}/{{fileName}}.content.json",
+    //
+    // fill: true, // générer automatiquement les traductions manquantes pour tous les dictionnaires comme en utilisant "./{{fileName}}.content.json"
+    //
+    // fill: {
+    //   en: "./{{fileName}}.en.content.json",
+    //   fr: "./{{fileName}}.fr.content.json",
+    //   es: "./{{fileName}}.es.content.json",
+    // },
+  },
+};
+
+export default config;
+```
+
+Vous pouvez toujours affiner par dictionnaire en utilisant le champ `fill` dans les fichiers de contenu. Intlayer considérera d'abord la configuration par dictionnaire et reviendra ensuite à la configuration globale.
+
 ## Format du fichier rempli automatiquement
 
 Le format recommandé pour les fichiers de déclaration remplis automatiquement est **JSON**, ce qui permet d'éviter les contraintes de formatage. Cependant, Intlayer prend également en charge les formats `.ts`, `.js`, `.mjs`, `.cjs` et d'autres.

package/docs/fr/benchmark/solid.md

@@ -118,6 +118,28 @@ Nous avons comparé **quatre stratégies de chargement** :
 - **Scoped static** : Organise bien le code (séparation logique) sans requêtes réseau supplémentaires complexes.
 - **Scoped dynamic** : Meilleure approche pour le _code splitting_ et la performance. Minimise la mémoire en ne chargeant que ce dont la vue actuelle et la locale active ont besoin.
 
+### Ce que j'ai mesuré :
+
+J'ai exécuté la même application multilingue dans un vrai navigateur pour chaque stack, puis j'ai noté ce qui s'est réellement affiché sur le fil et le temps que cela a pris. Les tailles sont rapportées **après une compression web normale**, car c'est plus proche de ce que les gens téléchargent que les comptages de sources brutes.
+
+- **Taille de la bibliothèque d'internationalization** : Après bundling, tree-shaking et minification, la taille de la bibliothèque i18n est la taille du code des providers + hooks/primitives dans un composant vide. Elle n'inclut pas le chargement des fichiers de traduction. Elle répond à la question : à quel point la bibliothèque est-elle coûteuse avant que votre contenu ne soit pris en compte.
+
+- **JavaScript par page** : Pour chaque route de benchmark, combien de script le navigateur récupère lors de cette visite, moyenné sur les pages de la suite (et sur les locales où le rapport les agrège). Les pages lourdes sont des pages lentes.
+
+- **Fuite d'autres locales** : C'est le contenu de la même page mais dans une autre langue qui serait chargé par erreur dans la page auditée. Ce contenu est inutile et devrait être évité. (par exemple, le contenu de la page `/fr/about` dans le bundle de la page `/en/about`)
+
+- **Fuite d'autres routes** : La même idée pour les **autres écrans** de l'application : si leur contenu se charge quand vous n'avez ouvert qu'une seule page. (par exemple, le contenu de la page `/en/about` dans le bundle de la page `/en/contact`). Un score élevé indique un découpage faible ou des bundles trop larges.
+
+- **Taille moyenne du bundle du composant** : Les éléments d'interface communs sont mesurés **un à la fois** au lieu de se cacher dans un gigantesque numéro d'application. Cela montre si l'internationalization gonfle silencieusement les composants courants. Par exemple, si votre composant se rerender, il chargera toutes ces données de la mémoire. Attacher un énorme JSON à n'importe quel composant, c'est comme connecter un grand magasin de données inutilisées qui ralentira les performances de vos composants.
+
+- **Réactivité du changement de langue** : Je bascule la langue en utilisant le contrôle propre de l'application et je chronométre le temps qu'il faut jusqu'à ce que la page se soit clairement changée, ce qu'un visiteur remarquerait, et non une micro-étape de laboratoire.
+
+- **Travail de rendu après un changement de langue** : Un suivi plus étroit : combien d'effort l'interface a dû faire pour se repeindre pour la nouvelle langue une fois le changement en cours. Utile quand le temps « ressenti » et le coût du framework divergent.
+
+- **Temps de chargement initial de la page** : De la navigation à la considération par le navigateur que la page est complètement chargée pour les scénarios que j'ai testés. Bon pour comparer les démarrages à froid.
+
+- **Temps d'hydratation** : Quand l'application l'expose, le temps que le client passe à transformer le HTML du serveur en quelque chose que vous pouvez réellement cliquer. Un tiret dans les tableaux signifie que cette implémentation n'a pas fourni de chiffre d'hydratation fiable dans ce benchmark.
+
 ## Étoiles GitHub
 
 Les étoiles GitHub sont un indicateur fort de la popularité d'un projet, de la confiance de la communauté et de sa pertinence à long terme. Bien qu'elles ne soient pas une mesure directe de la qualité technique, elles reflètent le nombre de développeurs qui trouvent le projet utile, suivent ses progrès et sont susceptibles de l'adopter. Pour estimer la valeur d'un projet, les étoiles aident à comparer l'attraction entre les alternatives et fournissent des informations sur la croissance de l'écosystème.

package/docs/fr/benchmark/svelte.md

@@ -116,6 +116,28 @@ Nous avons comparé **quatre stratégies de chargement** :
 - **Scoped static** : Organise bien le code (séparation logique) sans requêtes réseau supplémentaires complexes.
 - **Scoped dynamic** : Meilleure approche pour le _code splitting_ et la performance. Minimise la mémoire en ne chargeant que ce dont la vue actuelle et la locale active ont besoin.
 
+### Ce que j'ai mesuré :
+
+J'ai exécuté la même application multilingue dans un vrai navigateur pour chaque stack, puis j'ai noté ce qui s'est réellement affiché sur le réseau et combien de temps cela a pris. Les tailles sont rapportées **après la compression web normale**, car c'est plus proche de ce que les gens téléchargent que les nombres de sources brutes.
+
+- **Taille de la bibliothèque d'internationalisation** : Après bundling, tree-shaking et minification, la taille de la bibliothèque i18n est la taille du code des providers + stores dans un composant vide. Elle n'inclut pas le chargement des fichiers de traduction. Elle répond à la question de savoir à quel point la bibliothèque est coûteuse avant que votre contenu n'entre en jeu.
+
+- **JavaScript par page** : Pour chaque route benchmark, la quantité de script que le navigateur récupère lors de cette visite, en moyenne sur les pages de la suite (et sur les locales lorsque le rapport les agrège). Les pages lourdes sont des pages lentes.
+
+- **Fuite d'autres locales** : C'est le contenu de la même page mais dans une autre langue qui serait chargé par erreur dans la page auditée. Ce contenu est inutile et devrait être évité. (par ex. le contenu de la page `/fr/about` dans le bundle de la page `/en/about`)
+
+- **Fuite d'autres routes** : La même idée pour **autres écrans** dans l'application : que leur contenu soit chargé quand vous n'avez ouvert qu'une seule page. (par ex. le contenu de la page `/en/about` dans le bundle de la page `/en/contact`). Un score élevé indique un splitting faible ou des bundles trop larges.
+
+- **Taille moyenne du bundle de composant** : Les éléments UI courants sont mesurés **un par un** au lieu de se cacher dans un énorme nombre d'applications. Elle montre si l'internationalisation gonfle silencieusement les composants quotidiens. Par exemple, si votre composant effectue un re-render, il chargera toutes ces données de la mémoire. Attacher un énorme JSON à n'importe quel composant, c'est comme connecter un grand magasin de données inutilisées qui ralentira les performances de vos composants.
+
+- **Réactivité du changement de langue** : Je bascule la langue en utilisant le contrôle propre de l'application et je mesure le temps qu'il faut jusqu'à ce que la page ait clairement basculé, ce qu'un visiteur remarquerait, pas une micro-étape de lab.
+
+- **Travail de rendu après un changement de langue** : Un suivi plus étroit : combien d'effort l'interface a pris pour se repeindre pour la nouvelle langue une fois le changement en cours. Utile quand le temps « ressenti » et le coût du framework divergent.
+
+- **Temps de chargement initial de la page** : De la navigation au navigateur considérant la page entièrement chargée pour les scénarios que j'ai testés. Bon pour comparer les démarrages à froid.
+
+- **Temps d'hydratation** : Lorsque l'application l'expose, combien de temps le client passe à transformer le HTML du serveur en quelque chose que vous pouvez réellement cliquer. Un tiret dans les tableaux signifie que cette implémentation n'a pas fourni de chiffre d'hydratation fiable dans ce benchmark.
+
 ## Étoiles GitHub
 
 Les étoiles GitHub sont un indicateur fort de la popularité d'un projet, de la confiance de la communauté et de sa pertinence à long terme. Bien qu'elles ne soient pas une mesure directe de la qualité technique, elles reflètent le nombre de développeurs qui trouvent le projet utile, suivent ses progrès et sont susceptibles de l'adopter. Pour estimer la valeur d'un projet, les étoiles aident à comparer l'attraction entre les alternatives et fournissent des informations sur la croissance de l'écosystème.

package/docs/fr/benchmark/tanstack.md

@@ -124,6 +124,28 @@ Nous avons comparé **quatre stratégies de chargement** :
 - **Scoped static** : Organise bien le code (séparation logique) sans requêtes réseau supplémentaires complexes.
 - **Scoped dynamic** : Meilleure approche pour le _code splitting_ et la performance. Minimise la mémoire en ne chargeant que ce dont la vue actuelle et la locale active ont besoin.
 
+### Ce que j'ai mesuré :
+
+J'ai exécuté la même application multilingue dans un vrai navigateur pour chaque stack, puis j'ai noté ce qui s'est réellement affiché sur le réseau et combien de temps cela a pris. Les tailles sont rapportées **après une compression web normale**, car cela se rapproche davantage de ce que les gens téléchargent que des nombres de sources brutes.
+
+- **Taille de la bibliothèque d'internationalisation** : Après bundling, tree-shaking et minification, la taille de la bibliothèque i18n est la taille des providers (par ex. `NextIntlClientProvider`) + hooks (par ex. `useTranslations`) code dans un composant vide. Cela n'inclut pas le chargement des fichiers de traduction. Cela répond à la question de savoir combien coûte la bibliothèque avant que votre contenu n'entre en jeu.
+
+- **JavaScript par page** : Pour chaque route de benchmark, combien de script le navigateur télécharge lors de cette visite, en moyenne sur les pages de la suite (et sur les locales où le rapport les agrège). Les pages lourdes sont des pages lentes.
+
+- **Fuite d'autres locales** : C'est le contenu de la même page mais dans une autre langue qui serait chargé par erreur dans la page auditée. Ce contenu est inutile et doit être évité. (par ex. contenu de la page `/fr/about` dans le bundle de la page `/en/about`)
+
+- **Fuite d'autres routes** : La même idée pour **les autres écrans** de l'application : si leur copie est chargée lorsque vous n'avez ouvert qu'une seule page. (par ex. contenu de la page `/en/about` dans le bundle de la page `/en/contact`). Un score élevé suggère un fractionnement faible ou des bundles trop larges.
+
+- **Taille moyenne du bundle de composant** : Les éléments d'interface utilisateur courants sont mesurés **un à la fois** au lieu de se cacher dans un énorme nombre d'applications. Cela montre si l'internationalisation augmente discrètement les composants ordinaires. Par exemple, si votre composant se re-render, il chargera toutes ces données depuis la mémoire. Attacher un énorme JSON à n'importe quel composant, c'est comme connecter un grand magasin de données inutilisées qui ralentira les performances de vos composants.
+
+- **Réactivité du changement de langue** : Je bascule la langue en utilisant le contrôle de l'application et je mesure le temps qu'il faut jusqu'à ce que la page ait clairement basculé, ce qu'un visiteur remarquerait, pas une micro-étape de laboratoire.
+
+- **Travail de rendu après un changement de langue** : Un suivi plus étroit : combien d'effort l'interface a dû fournir pour se redessiner dans la nouvelle langue une fois le changement en vol. Utile lorsque le temps « ressenti » et le coût du framework divergent.
+
+- **Temps de chargement initial de la page** : De la navigation à la considération par le navigateur de la page comme entièrement chargée pour les scénarios que j'ai testés. Bon pour comparer les démarrages à froid.
+
+- **Temps d'hydratation** : Quand l'application l'expose, combien de temps le client passe à transformer du HTML serveur en quelque chose sur lequel vous pouvez réellement cliquer. Un tiret dans les tableaux signifie que cette implémentation n'a pas fourni de chiffre d'hydratation fiable dans ce benchmark.
+
 ## Étoiles GitHub
 
 Les étoiles GitHub sont un indicateur fort de la popularité d'un projet, de la confiance de la communauté et de sa pertinence à long terme. Bien qu'elles ne soient pas une mesure directe de la qualité technique, elles reflètent le nombre de développeurs qui trouvent le projet utile, suivent ses progrès et sont susceptibles de l'adopter. Pour estimer la valeur d'un projet, les étoiles aident à comparer l'attraction entre les alternatives et fournissent des informations sur la croissance de l'écosystème.

package/docs/fr/cli/ci.md

@@ -140,6 +140,28 @@ steps:
     run: npx intlayer ci fill
 ```
 
+## GitHub Actions générés automatiquement
+
+Lorsque vous exécutez `intlayer init`, Intlayer détecte votre gestionnaire de paquets (npm, yarn, pnpm, ou bun) et génère automatiquement deux workflows GitHub Actions sous `.github/workflows/`, avec des commandes correspondant à ce gestionnaire de paquets :
+
+- **`intlayer-fill.yml`** — Sur chaque pull request, construit les dictionnaires et exécute `intlayer fill --git-diff --mode complete` pour générer les traductions manquantes pour les dictionnaires modifiés, puis valide le résultat sur la branche PR.
+- **`intlayer-test.yml`** — Sur chaque pull request, construit les dictionnaires et exécute `intlayer test`, échouant la vérification si les locales requises ont des traductions manquantes.
+
+Les fichiers de workflow existants ne sont jamais écrasés. Pour ignorer complètement la génération automatique, exécutez :
+
+```bash
+npx intlayer init --no-github-actions
+```
+
+### Fournir un accès IA au workflow de remplissage
+
+Le fichier `intlayer-fill.yml` généré nécessite un accès IA. Deux options sont disponibles (configurées dans le bloc `env` du workflow) :
+
+1. **Votre propre clé de fournisseur IA** — Ajoutez un secret `AI_API_KEY` dans les paramètres de votre référentiel (Settings → Secrets and variables → Actions). Le workflow le transmet via `--provider`, `--model` et `--api-key`.
+2. **Clés d'accès Intlayer CMS** — Ajoutez les secrets `INTLAYER_CLIENT_ID` et `INTLAYER_CLIENT_SECRET` et intégrez-les dans la section `editor` de votre `intlayer.config`. Les clés d'accès CMS accordent l'accès IA via le backend Intlayer.
+
+Le workflow `intlayer-test.yml` ne nécessite aucun accès IA.
+
 ## Gestion des erreurs
 
 - Si `INTLAYER_PROJECT_CREDENTIALS` n'est pas définie, la commande se terminera avec une erreur.