CLI-ReferenzÜbersicht

Übersicht

Der Befehl verbatra: seine neun Unterbefehle, die gemeinsamen Flags, wie er deine Umgebung liest und der Exit-Code-Vertrag.

Maschinell übersetzte Seite

Diese Seite wurde automatisch übersetzt und kann daher Fehler oder seltsame Formulierungen enthalten. Die englische Version ist die maßgebliche Quelle. Das englische Original lesen.

@verbatra/cli liefert das verbatra-Binary, einen dünnen Wrapper über @verbatra/sdk. Neun Befehle erledigen die Arbeit:

BefehlWas er tut
initeine verbatra-Konfiguration und .env.example für dieses Projekt anlegen
translatejedes Ziel-Locale einmal übersetzen, dann beenden
watchbei jeder Quelländerung neu übersetzen, bis unterbrochen wird
checkmelden, welche Keys pro Locale fehlen oder veraltet sind, schreibgeschützt
diffdie genauen Keys pro Locale listen, die hinzugefügt oder neu übersetzt würden oder verwaist sind, schreibgeschützt
doctordie Projekteinrichtung prüfen und alle Probleme auf einmal melden, ohne einen Provider aufzurufen
exportunübersetzte Strings in eine Excel-Arbeitsmappe für eine menschliche Übersetzerin exportieren
importeine ausgefüllte Arbeitsmappe zurück in die Locale-Dateien importieren
studioVerbatra Studio starten, das lokale Übersetzungs-Dashboard

Installieren und aufrufen

Installiere @verbatra/cli als Dev-Dependency und starte das Binary über deinen Paketmanager:

npm install --save-dev @verbatra/cli
npx verbatra translate       # or: pnpm verbatra translate, yarn verbatra translate

Du brauchst Node.js >=22.14.0.

Gemeinsame Konventionen

  • --cwd <path> löst die Konfiguration und die Locale-Dateien von diesem Verzeichnis statt vom aktuellen aus auf. Jeder Befehl nimmt es.
  • --config <path> lädt diese Konfigurationsdatei, statt eine zu suchen. Jeder Befehl außer init nimmt es; die Suchreihenfolge steht in Konfigurationsdatei.
  • --json gibt einen maschinenlesbaren Envelope auf stdout aus, eine Zeile pro Datensatz, und hält stdout sauber zum Weiterleiten. Verzweige auf sein ok-Feld: ein Erfolg trägt die Daten des Befehls unter result, ein fehlgeschlagener Lauf trägt denselben stabilen Fehlercode, den auch die stderr-Zeile nennt. Die menschenlesbare Fehlerzeile geht in beiden Fällen auf stderr. translate, watch, check, diff, doctor, export und import unterstützen es; init und studio nicht.
  • --help und --version geben aus und enden mit 0. Ein unbekannter Befehl oder ein unbekanntes Flag endet mit 2.

Umgebungsdateien

translate, watch, doctor und studio laden .env.local und dann .env aus dem Arbeitsverzeichnis, bevor sie laufen. Eine bereits in deiner echten Umgebung gesetzte Variable gewinnt immer. API-Keys werden nur aus der Umgebung gelesen, nie aus der Konfigurationsdatei oder einem Flag: siehe Provider. Die schreibgeschützten Befehle (check, diff) und die Arbeitsmappen-Befehle (export, import) rufen nie einen Provider auf und laden keine .env-Dateien.

Exit-Codes

Der Exit-Code ist der Vertrag, auf den ein CI-Schritt oder Skript verzweigt:

CodeBedeutung
0Erfolg (auch --help und --version)
1translate oder import lief durch, aber einige Locales schlugen fehl oder blieben partial, check fand ein Locale nicht synchron, diff fand ausstehende Änderungen, oder doctor fand ein Einrichtungsproblem
2konnte nicht laufen: ein Fehler des gesamten Laufs (Konfiguration, Quelle, Provider, Lock) oder ein Verwendungsfehler
130watch oder studio wurde durch einen zweiten Interrupt zwangsbeendet

Jede Befehlsseite erklärt, wie diese Codes für sie gelten. Wie du sie in eine Pipeline einbaust, steht in CI und Exit-Codes.

Edit on GitHub