Konfiguration

Der persistente Zustand der CLI liegt an drei Stellen: zwei im Projekt (eingecheckt), eine in Ihrem Home-Verzeichnis (rechnerbezogen).

.lingo/config.json — eingecheckt#

Erstellt von lingo init (Lokalisierungsabschnitt) und lingo link (Org-/Engine-Zuordnung). Checken Sie die Datei ein.

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

Feldreferenz#

Muster → Zielzuordnung#

Die CLI ersetzt die Quellsprache im Muster durch jede Zielsprache:

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

Wenn Ihr Quelllayout keinen Sprachcode im Pfad enthält, strukturieren Sie es um. Ohne ihn kann die CLI nicht ableiten, wohin die Zieldateien geschrieben werden sollen.

.lingo/lock.json — eingecheckt#

Speichert den zuletzt bekannten Server-Hash jeder Quell- und Zieldatei. Das wird für zwei Dinge verwendet:

1. lingo push nutzt ihn, um festzustellen, ob sich eine Quelle seit dem letzten erfolgreichen Lauf geändert hat. Unveränderte Dateien werden zum No-op — ohne Roundtrip zum Server.
2. lingo pull nutzt ihn, um lokale Änderungen an Zieldateien zu erkennen — wenn der Hash eines lokalen Ziels von dem abweicht, was die Lockfile angibt, würde Pull lokale Arbeit überschreiben. Deshalb bricht pull mit einem Fehler ab, außer Sie übergeben --force.

Quell-Hashes werden erst nach einem vollständig erfolgreichen Push in die Lockfile geschrieben, sodass ein nur teilweise abgeschlossener Lauf ohne manuelles Aufräumen erneut versucht werden kann.

Checken Sie die Lockfile zusammen mit den übersetzten Ausgaben ein. Behandeln Sie Konflikte so, wie Sie auch package-lock.json-Konflikte behandeln würden: einfach neu erzeugen, indem Sie lingo push erneut ausführen.

~/.lingo/runs/<hash>.json — rechnerbezogen#

Speichert die zuletzt übermittelte push, damit lingo pull weiß, aus welchem Lauf die Ausgaben abgerufen werden müssen — auch über geschlossene Terminals hinweg und auf Rechnern mit demselben Checkout.

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

Der Hash im Dateinamen wird aus dem absoluten Pfad des Projektwurzelverzeichnisses abgeleitet, nicht aus Dateiinhalten. Das bedeutet:

• Wenn Sie en.json bearbeiten, wird die Datei dadurch nicht ungültig — dieselbe pull findet den Lauf weiterhin.
• Zwei Checkouts desselben Repos auf demselben Rechner erhalten unterschiedliche Dateien (wegen unterschiedlicher absoluter Pfade).
• Wenn Sie das Projekt (mv ~/Projects/foo ~/Projects/bar) zwischen Push und Pull verschieben, wird die Zuordnung ungültig, weil sich der Hash ändert. Das JSON liegt aber weiterhin in ~/.lingo/runs/, falls Sie die Lauf-ID manuell wiederherstellen müssen.

Diese Datei ist rechnerbezogener Zustand, kein Projektzustand — sie wird nicht per gitignore ausgeschlossen, weil sie vollständig außerhalb des Repos liegt.

Anmeldedaten — ~/.lingo/auth.json#

Gespeichert von lingo login (der OTP-Flow speichert eine Supabase-Sitzung; der --api-key-Flow speichert den Schlüssel). Wird nicht eingecheckt und nie von etwas anderem als der CLI selbst gelesen.

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

Auflösung aus Unterverzeichnissen#

Jeder Befehl geht von cwd aus nach oben und sucht nach der nächstgelegenen .lingo/config.json. Wenn Sie lingo push aus src/components/ ausführen, wird die Lockfile zurück ins Projektwurzelverzeichnis geschrieben, nicht als neue .lingo/ in components/. Sie müssen also nicht vor jedem Befehl erst per cd ins Root-Verzeichnis wechseln.