Configuration

L’état persistant du CLI est stocké à trois endroits : deux dans le projet (versionnés), un dans votre répertoire personnel (propre à la machine).

.lingo/config.json — versionné#

Créé par lingo init (section localisation) et lingo link (liaison org/moteur). Versionnez-le.

{
  "orgId": "org_a8c...",
  "engineId": "eng_b9d...",
  "sourceLocale": "en",
  "targetLocales": ["de", "fr", "es"],
  "files": [
    { "pattern": "locales/en.json" },
    { "pattern": "docs/en/**/*.md" }
  ]
}

Référence des champs#

Correspondance motif → cible#

Le CLI remplace la langue source du motif par chaque langue cible :

• locales/en.json → locales/de.json, locales/fr.json, ...
• docs/en/**/*.md → docs/de/**/*.md (arborescence miroir)
• copy/en/marketing.md → copy/de/marketing.md

Si la structure de vos sources n’inclut pas le code de langue dans le chemin, il faut la revoir. Sans cela, le CLI ne peut pas déterminer où écrire les fichiers cibles.

.lingo/lock.json — versionné#

Suit le dernier hash serveur connu de chaque fichier source et cible. Il sert à deux choses :

1. lingo push s’en sert pour déterminer si une source a changé depuis la dernière exécution réussie. Les fichiers inchangés deviennent alors un no-op, sans aller-retour vers le serveur.
2. lingo pull s’en sert pour détecter les modifications locales des cibles — si le hash d’une cible locale diffère de celui indiqué dans le lockfile, un pull écraserait le travail local ; pull renvoie donc une erreur, sauf si vous passez --force.

Les hash des sources ne sont enregistrés dans le lockfile qu’après un push entièrement réussi, afin qu’une exécution partiellement terminée puisse être relancée sans nettoyage manuel.

Versionnez le lockfile avec les sorties traduites. Traitez les conflits comme vous traiteriez des conflits package-lock.json : régénérez-le en relançant lingo push.

~/.lingo/runs/<hash>.json — propre à la machine#

Enregistre le push soumis le plus récemment afin que lingo pull sache de quelle exécution récupérer les sorties — y compris après la fermeture du terminal et sur des machines qui partagent le même checkout.

{
  "runId": "run_a8c...",
  "engineId": "eng_b9d...",
  "organizationId": "org_a8c...",
  "sourceLocale": "en",
  "createdAt": "2026-05-22T14:32:01.000Z"
}

Le hash du nom de fichier est dérivé du chemin racine absolu du projet, et non du contenu des fichiers. Donc :

• Modifier en.json n’invalide pas le fichier — le même pull retrouvera toujours l’exécution.
• Deux checkouts du même dépôt sur une même machine obtiennent des fichiers distincts (puisque leurs chemins absolus diffèrent).
• Déplacer le projet (mv ~/Projects/foo ~/Projects/bar) entre le push et le pull invalide la recherche, puisque le hash change. Le JSON reste disponible dans ~/.lingo/runs/ si vous devez récupérer manuellement l’ID d’exécution.

Ce fichier correspond à un état propre à la machine, et non au projet — il n’est pas gitignored, car il se trouve entièrement en dehors du dépôt.

Identifiants d’authentification — ~/.lingo/auth.json#

Stockés par lingo login (le flux OTP stocke une session Supabase ; le flux --api-key stocke la clé). Ils ne sont pas versionnés et ne sont jamais lus par autre chose que le CLI lui-même.

lingo logout         # clear credentials
lingo whoami         # check what's stored and which org/engine the cwd resolves to

Résolution depuis les sous-répertoires#

Chaque commande remonte depuis cwd à la recherche du .lingo/config.json le plus proche. Exécuter lingo push depuis src/components/ écrit son lockfile à la racine du projet, et non un nouveau .lingo/ dans components/. Vous n’avez donc pas besoin de cd jusqu’à la racine avant chaque commande.