|
Documentation
Réserver une démoPlateforme
PlateformeMCPCLIAPIWorkflows
Guides
Changelog

Localisation

  • Aperçu
  • API de traduction
  • Localisation d’applications web
  • Localisation d’apps mobiles
  • iOS avec String Catalogs
  • Android avec strings.xml
  • Localisation des e-mails
  • Contenu statique (ex. : .md, .json)
  • Next.js avec Markdoc
  • Rails avec i18n

Workflows

  • Configurer un moteur avec le MCP
  • Triage Jira
  • CI/CD

Localisation d’applications web

Le CLI de Lingo.dev traduit les fichiers de ressources de votre application web — JSON, YAML, XLIFF, PO ou PHP — via un moteur de localisation configuré. Configurez l’i18n dans votre framework, pointez le CLI vers vos fichiers de traduction, puis lancez la commande.

Comment ça marche#

Chaque framework web s’appuie sur une bibliothèque i18n qui charge les traductions depuis des fichiers de ressources — JSON pour React, XLIFF pour Angular, PO pour Django, etc. Le CLI traduit directement ces fichiers pour que le framework récupère les traductions sans aucune modification du code.

1

Configurer l’i18n dans votre framework

Utilisez la bibliothèque i18n officielle de votre framework pour ajouter un routage adapté à la langue, une fonction de traduction et des fichiers de ressources dans la langue source. Chaque section ci-dessous renvoie vers le guide de configuration officiel du framework concerné.

2

Configurer le CLI

Exécutez lingo init pour créer un .lingo/config.json avec vos langues source et cibles, ainsi que les motifs de fichiers à traduire, puis lingo link pour y associer votre organisation et votre moteur. Le CLI détecte automatiquement le format de chaque fichier à partir de son extension : aucun type de bucket n'est donc nécessaire. Validez .lingo/config.json.

3

Lancer les traductions

Exécutez lingo push et le CLI traduit vos fichiers de ressources via le moteur de localisation — règles de glossaire, voix de marque et sélection du modèle s’appliquent automatiquement.

Prérequis#

Installez le CLI et authentifiez-vous :

bash
npm install -g @lingo.dev/cli
lingo login

Le CLI nécessite Node.js 22+. En CI, ignorez la connexion interactive et fournissez une clé avec --api-key ou via la variable d'environnement LINGO_API_KEY.

À chaque exécution, le CLI envoie le contenu via un moteur de localisation — la configuration qui détermine le modèle LLM, le glossaire, la voix de marque et les règles à appliquer. Créez-en un dans le tableau de bord Lingo.dev, puis générez une clé API. lingo link écrit le orgId et le engineId du moteur dans .lingo/config.json.

Configuration assistée par IA

Le i18n MCP peut générer automatiquement toute l’infrastructure i18n de votre framework. Connectez-le à Claude Code, Cursor ou GitHub Copilot, puis saisissez « Set up i18n » — l’agent suit une checklist en 13 étapes pour configurer le routage, les fichiers de traduction et un sélecteur de langue.

Frameworks JavaScript#

Le segment de langue dans chaque pattern est remplacé pour chaque langue cible : public/locales/en/translation.json devient public/locales/de/translation.json, et ainsi de suite. Le chemin source doit contenir le code de la langue source.

react-i18next charge les traductions depuis des fichiers JSON et fournit un hook useTranslation qui associe les clés aux chaînes traduites à l’exécution.

json
{
  "orgId": "org_...",
  "engineId": "eng_...",
  "sourceLocale": "en",
  "targetLocales": ["es", "fr", "de", "ja"],
  "files": [{ "pattern": "public/locales/en/translation.json" }]
}

Frameworks côté serveur#

Laravel inclut une localisation intégrée qui charge les traductions depuis des fichiers PHP organisés par répertoire de langue.

json
{
  "orgId": "org_...",
  "engineId": "eng_...",
  "sourceLocale": "en",
  "targetLocales": ["es", "fr", "de", "ja"],
  "files": [{ "pattern": "lang/en/messages.php" }]
}

Lancer les traductions#

Une fois .lingo/config.json en place, traduisez tous les fichiers de ressources en une seule commande :

bash
lingo push

Le CLI lit vos fichiers de langue source, calcule ce qui a changé depuis la dernière exécution à l'aide du lockfile (.lingo/lock.json, validé avec votre configuration), traduit uniquement le delta et écrit les résultats dans les fichiers de langue cible. Les traductions existantes sont préservées : le CLI ne remplit que les chaînes manquantes ou mises à jour.

Lors de la première exécution, ou après l'ajout d'une nouvelle langue cible, retraduisez l'ensemble depuis zéro :

bash
lingo push --backfill-missing

Limitez une exécution à un sous-ensemble de fichiers en passant un glob :

bash
lingo push "messages/**"

Pour récupérer les dernières traductions ailleurs (par exemple sur une autre machine ou dans une étape de build) sans traduire, exécutez lingo pull. Utilisez lingo check comme garde-fou de déploiement pour vérifier que les traductions sont à jour.

Étapes suivantes#

Exemples de projets
Des dépôts React, Next.js, Laravel et Rails prêts à l’emploi, avec la configuration et les traductions déjà intégrées
Configuration du CLI
Référence complète de .lingo/config.json : fichiers, codes de langue et options avancées
Formats pris en charge
Tous les formats de fichiers que le CLI peut traduire
App GitHub
Automatisez les traductions à chaque push, côté serveur, sans runner ni secret
i18n MCP
Configuration i18n assistée par IA pour votre framework

Cette page vous a-t-elle été utile ?

Max PrilutskiyMax Prilutskiy·Mis à jour il y a 13 jours·5 min de lecture