Mode serveurPostgres + auth centrale
Multi-équipes, vérifié par JWT via JWKS. Le webapp valide les tokens hors ligne via le point de terminaison /api/auth/.well-known/jwks.json de votre serveur d'authentification.
Documentation
Livrez vos traductions en toute confiance
Tout ce qu'il faut pour installer, configurer, déployer et maintenir i18n Dashboard — que vous soyez développeur solo ou équipe d'entreprise.
Démarrage rapide avec Docker
L'image officielle arnaudprioul/i18n-dashboard est disponible sur Docker Hub pour linux/amd64 et linux/arm64. Trois façons de l'exécuter selon la taille de votre équipe.
Mode localSQLite, sans auth
Un seul utilisateur, une seule équipe. Les traductions vivent dans un volume Docker. Idéal pour de l'auto-hébergement jusqu'à ~100k clés. Enregistrez ceci sous docker-compose.yml et exécutez docker compose up -d :
Lié à
127.0.0.1 uniquement par défaut : accessible depuis cette machine, pas depuis les autres appareils du réseau. Le mode local n'a pas d'écran de connexion, donc quiconque atteint le port aurait accès à tous les projets — n'élargissez cette liaison que derrière un pare-feu ou un VPN de confiance.Guide complet, variables d'environnement et dépannage sur la page Docker Hub.
Mode desktopTauri, données locales
Build natif macOS / Windows / Linux avec serveur Nitro embarqué et SQLite. Pas de Docker, aucune base à configurer. La connexion passe par votre compte en ligne.
- macOS
- Windows
- Linux
Trouvez ce que vous cherchez
Huit groupes : prise en main, guides par framework, déploiement, administration, qualité, référence, facturation et support.
Prise en main
Guides par framework
Déploiement
Administration
- Configuration SMTP
Vérification d'email et réinitialisation de mot de passe.
- Fournisseurs de traduction
Google, DeepL, Claude, Gemini, Mistral, LibreTranslate.
- Rôles utilisateurs et permissions
Admin, Modérateur, Traducteur. Connexion via votre compte central.
- Webhooks & intégrations
Slack, Discord, GitHub Action, GitLab CI.
- Sauvegarde & restauration
Sauvegarde JSON, import fusion/remplacement, commandes CLI.
Qualité & collaboration
- Contrôles qualité
Validation des placeholders, alertes de longueur, vérifications HTML, aperçu RTL.
- Glossaire & guides de style
Assurez une terminologie cohérente par langue.
- Suggestions par clé similaire
Réutilisez des traductions similaires grâce au scoring.
- Branches
Travaillez sur des traductions isolées avant de fusionner.
Référence
Facturation & tarifs
Support
Variables d'environnement
Chaque valeur runtimeConfig peut être surchargée au runtime via le préfixe NUXT_* — la convention canonique de Nitro. Les noms simples comme I18N_DB_HOST sont ignorés silencieusement sauf s'ils sont explicitement listés comme variables du protocole.
La référence complète (chaque variable, sa valeur par défaut, sa portée et une note de migration) se trouve sur la page Docker Hub, au plus près de l'image :
Ouvrir la référence complète des variables sur Docker Hub →Réglages les plus courants
I18N_APP_MODE—local/server/desktop. Le mode serveur nécessite une vraie base de données et une auth centrale.NUXT_DB_CLIENT+NUXT_DB_HOST+NUXT_DB_NAME+NUXT_DB_USER+NUXT_DB_PASSWORD— Connexion Postgres / SQLite / MySQL.NUXT_SESSION_SECRET— requis en production. Générez-le avecopenssl rand -hex 32.NUXT_CENTRAL_AUTH_URL+NUXT_PUBLIC_CENTRAL_AUTH_URL— URLs côté serveur et côté navigateur de votre émetteur d'authentification (doit être compatible JWKS).NUXT_AUTH_JWT_ISSUER+NUXT_AUTH_JWT_AUDIENCE— les claimsiss/audattendus sur les jetons d'accès.NUXT_INTERNAL_API_SECRET— HMAC partagé pour les appels internes webapp ↔ auth centrale. Doit être identique des deux côtés.NUXT_SMTP_HOST+NUXT_SMTP_PORT+NUXT_SMTP_USER+NUXT_SMTP_PASS+NUXT_SMTP_FROM— notifications de workflow. Laissez l'hôte vide pour désactiver l'email.NUXT_DASHBOARD_URL— l'URL publique de cette instance webapp, utilisée dans les liens des emails transactionnels.
Configuration SMTP en 30 secondes
Choisissez un relais SMTP et renseignez les quatre valeurs ci-dessous — l'image enverra les emails via ce relais à chaque événement de workflow.
Pour le développement local ou des tests rapides, utilisez le service Mailpit embarqué : NUXT_SMTP_HOST=mailpit, NUXT_SMTP_PORT=1025.
Rôles et permissions
Un rôle est attribué par projet, pas à l'échelle de l'instance — trois paliers, chacun débloquant davantage de ce que ce projet autorise.
translator | moderator | admin | super_admin | |
|---|---|---|---|---|
| Modifier les traductions | Oui | Oui | Oui | Oui |
| Valider les traductions | Non | Oui | Oui | Oui |
| Gérer le projet (paramètres, scan, sync) | Non | Non | Oui | Oui |
| Gérer les membres du projet | Non | Non | Oui | Oui |
Attribuez un rôle depuis la page Users d'un projet — choisissez un membre, puis translator, moderator ou admin. Un admin sur un projet n'a aucun pouvoir sur les autres projets, ni sur le compte qui les possède.
Le drapeau super_admin
super_admin est indépendant de tout rôle de projet — un drapeau au niveau du compte qui contourne tous les contrôles ci-dessus, sur tous les projets. Il est attribué automatiquement au premier compte créé sur une instance, que ce soit via l'assistant d'installation local ou lors de la toute première connexion en mode serveur, et il n'existe actuellement aucun moyen de promouvoir un autre compte super_admin depuis le tableau de bord.
Webhooks
Configurés par projet depuis Admin → Integrations (réservé à super_admin). Chaque webhook envoie une requête à votre point de terminaison à chaque événement souscrit sur ce projet.
Événements
Un webhook peut souscrire à n'importe lequel des événements suivants :
key.deleted— une ou plusieurs clés de traduction ont été suppriméestranslation.saved— une valeur de traduction a été enregistréescan.completed— un scan du code source pour les clés nouvelles ou modifiées s'est terminésync.completed— une synchronisation avec le fournisseur de traduction configuré s'est terminée
Vérifier une livraison
Chaque livraison vers un point de terminaison HTTP générique porte l'en-tête X-Webhook-Signature — un HMAC-SHA256 du corps JSON, avec le secret affiché une seule fois à la création du webhook — et X-Webhook-Event. Les URLs Slack et Discord sont détectées automatiquement et reçoivent le format de message propre à cette plateforme ; ces deux intégrations s'authentifient via l'URL elle-même, elles ne portent donc jamais d'en-tête de signature.
Exigences sur l'URL sortante
- Doit résoudre vers une adresse publique — les cibles loopback, privées (RFC1918/unique-local) et link-local sont rejetées, à la fois quand vous enregistrez l'URL et à nouveau à chaque tentative de livraison (y compris chaque saut de redirection), ce qui ferme la brèche où un nom d'hôte se résout différemment entre les deux moments.
- En production, le point de terminaison doit utiliser
https:— le HTTP simple n'est toléré qu'en dehors de la production. - Les identifiants intégrés dans l'URL (
https://user:pass@host) sont rejetés. - Une livraison expire après 10 secondes et suit au maximum 5 redirections.
Utilisez le bouton ▶ à côté d'un webhook pour envoyer un événement ping signé à la demande, sans attendre un événement réel.
Sauvegarde et restauration
Réservé à super_admin, depuis Admin → Backup ou la CLI. Une sauvegarde est un unique export JSON couvrant tous les projets, traductions, utilisateurs et paramètres.
Toujours exclus : refresh_tokens, password_reset_tokens, otp_tokens, webhook_deliveries, ainsi que le hash de mot de passe de chaque compte.
Depuis le tableau de bord
« Download backup » enregistre un fichier JSON daté, par ex. i18n-dashboard-backup-2026-07-31.json.
Restaurer consiste à réimporter ce fichier et à choisir un mode :
- merge (par défaut) conserve les lignes existantes et n'insère que ce qui manque
- replace supprime d'abord les données existantes de chaque table, puis importe — irréversible
Le résultat indique les lignes restaurées, les doublons ignorés et toute ligne en échec, plutôt que de signaler silencieusement un succès sur une restauration partielle.
Depuis la CLI
Les deux commandes nécessitent un jeton admin élevé — NUXT_CLI_ADMIN_TOKEN (repli sur NUXT_CLI_TOKEN) — passé avec --token, ou résolu depuis votre configuration CLI.
Dépannage
Les problèmes les plus fréquents chez les auto-hébergeurs, tirés directement du guide de dépannage de l'image Docker.
Refusing to start: NUXT_DB_HOST is still the build-time default 'localhost'— votre environnement utilise encore les anciens noms sans préfixe NUXT_*. Ajoutez le préfixe NUXT_ à vos variables de base de données (NUXT_DB_HOST, NUXT_DB_USER, …).Webapp returns 401 on every API call— le point de terminaison JWKS n'est pas joignable. Vérifiez que NUXT_CENTRAL_AUTH_URL est résoluble depuis l'intérieur du conteneur (utilisez le nom d'hôte du réseau Docker quand les deux services tournent dans le même compose).JWT verification fails right after a key rotation— le cache JWKS vit 1 heure et se rafraîchit 30 secondes après un échec de correspondance de clé. Prévoyez une courte marge, ou redémarrez la webapp juste après la rotation.Health check shows "0 keys" despite a non-empty database— vous touchez probablement la mauvaise base de données. Vérifiez que NUXT_DB_HOST est bien défini, plutôt que de retomber sur un fichier SQLite oublié.Container starts on port 3000 instead of 6001— Nitro lit directement PORT. L'image définit I18N_PORT=6001, mais surcharger PORT déplace le port d'écoute — gardez-le aligné avec votre mapping ports:.Can't reach the dashboard from another machine— attendu avec l'extrait Compose par défaut — le port est lié à 127.0.0.1 intentionnellement. Liez une adresse routable, ou placez un reverse proxy devant, pour l'exposer délibérément.