Automatiser les traductions i18n avec Next.js et GitHub
Gérer les traductions manuellement, c'est l'un des points de friction les plus courants dans les projets Next.js multilingues. Fichiers JSON désynchronisés, clés oubliées, Pull Requests qui s'accumulent pour des chaînes de texte — ce temps ne génère aucune valeur.
Ce guide montre comment mettre en place un pipeline de localisation continue : chaque modification de votre fichier source déclenche automatiquement une PR de traduction, dans toutes vos langues, sans intervention manuelle.
Pourquoi la gestion manuelle des traductions ne scale pas ?
Q : Quels sont les vrais problèmes du workflow i18n manuel ?
Trois problèmes s'accumulent systématiquement :
La lenteur. Entre l'ajout d'une clé dans le code et sa traduction disponible en production, il peut s'écouler plusieurs jours. Sur des cycles de déploiement rapides, c'est bloquant.
Le goulot humain. Une personne centralise les exports, les envois aux traducteurs, les imports. C'est fragile et ça ne scale pas au-delà d'une ou deux langues.
La dette de traduction. Les clés non traduites s'accumulent en silence. Dans certaines langues, des portions entières de l'interface restent dans la langue source sans que personne ne le remarque.
Q : Est-ce que ce workflow est entièrement automatisable ?
Oui. La chaîne complète — détection des nouvelles clés, traduction, création de la PR — peut être automatisée. C'est exactement ce que fait Jason.
Quelle librairie choisir pour Next.js ?
Q : next-intl ou i18next pour un projet Next.js en 2025 ?
Pour Next.js 13+ avec App Router, next-intl est le choix de référence. Elle est conçue pour le SSR et les Server Components : pas de provider côté client nécessaire pour les composants serveur, routing par locale intégré, support TypeScript natif.
Pour les apps React hors Next.js (Vite, CRA) ou Next.js Pages Router, i18next + react-i18next reste la solution la plus flexible et la plus documentée.
Mise en place avec next-intl
Installation
pnpm add next-intl
Structure recommandée
messages/
fr.json ← langue source (maintenu manuellement)
en.json ← généré automatiquement par Jason
es.json ← généré automatiquement
de.json ← généré automatiquement
src/
i18n.ts
middleware.ts
Configuration src/i18n.ts
import { getRequestConfig } from 'next-intl/server'
import { cookies } from 'next/headers'
export default getRequestConfig(async () => {
const locale = cookies().get('locale')?.value ?? 'fr'
return {
locale,
messages: (await import(`../messages/${locale}.json`)).default
}
})
next.config.js
const createNextIntlPlugin = require('next-intl/plugin')
const withNextIntl = createNextIntlPlugin('./src/i18n.ts')
module.exports = withNextIntl({})
Utilisation dans les composants
// Composant serveur
import { getTranslations } from 'next-intl/server'
export default async function PricingPage() {
const t = await getTranslations('pricing')
return <h1>{t('title')}</h1>
}
// Composant client
'use client'
import { useTranslations } from 'next-intl'
export default function NavBar() {
const t = useTranslations('nav')
return <a href="/pricing">{t('pricing')}</a>
}
Connecter GitHub pour la localisation continue
Q : Comment fonctionne la synchronisation GitHub avec Jason ?
En trois étapes :
- Connexion : connectez votre repository GitHub dans Jason et indiquez le chemin de votre fichier source (ex.
messages/fr.json) - Détection : à chaque push, Jason identifie les clés nouvelles ou modifiées
- PR automatique : Jason génère les traductions et ouvre une Pull Request sur votre repo, prête à merger
Q : Comment configurer le webhook GitHub ?
Dans Jason : Settings → Integrations → Generate webhook token.
Dans GitHub : Settings → Webhooks → Add webhook
| Champ | Valeur |
|-------|--------|
| Payload URL | URL fournie par Jason |
| Content type | application/json |
| Secret | Token Jason |
| Events | "Just the push event" |
Cliquez sur Add webhook. Le pipeline est actif.
Q : Est-ce compatible avec un pipeline CI/CD existant ?
Oui. Jason propose une API REST et un CLI pour déclencher les traductions depuis vos scripts de déploiement, en plus du webhook GitHub.
# Exemple CLI
jason translate --project mon-projet --source messages/fr.json --langs en,es,de
Variables, pluriels et cas particuliers
Q : Comment Jason gère-t-il les variables dans les clés ?
Jason détecte et préserve automatiquement tous les formats courants :
{ "welcome": "Bienvenue, {name} !" }
{ "cart": "{{count}} article(s) dans le panier" }
{ "keys": "{count, plural, =0 {Aucune clé} =1 {1 clé} other {# clés}}" }
La structure et les identifiants de variables sont reproduits à l'identique dans toutes les langues cibles, sans modification.
Q : Jason préserve-t-il la structure JSON imbriquée ?
Oui. La hiérarchie de votre fichier source est conservée. Si votre fr.json a une structure en namespaces (auth.login.submit), les fichiers générés ont exactement la même structure.
Résultat : localisation continue sans friction
Avec ce pipeline en place, la dette de traduction devient structurellement impossible. Chaque PR de code qui modifie le fichier source déclenche une PR de traduction. Vos langues sont toujours à jour.
Ce modèle — localisation continue intégrée au workflow de développement — est ce qui différencie les équipes qui gèrent bien leurs traductions de celles qui accumulent des clés manquantes sprint après sprint.