Einen Lauf rückgängig machen

Nutze das, wenn ein Lauf Übersetzungen erzeugt hat, die du nicht willst: den falschen Ton, das falsche Modell, ein vergessenes Glossar. verbatra hat keinen Rückgängig-Befehl und legt keine Sicherungen an. Die Versionsverwaltung ist der Wiederherstellungsweg, und deshalb werden die Locale-Dateien, die Lock-Datei und die Herkunftsdatei committet: Zusammen sind sie der Stand, zu dem du zurückkehrst.

Du brauchst das Projekt in git, mit dem Stand vor dem Lauf committet.

Was ein Lauf schreibtLink zu diesem Abschnitt kopieren

Ein translate-, watch- oder import-Lauf schreibt die Dateien, um die sich ein Rollback kümmern muss:

• die Ziel-Locale-Dateien unter deinem files.pattern;
• verbatra.lock.json, ein Hash des Quellinhalts pro übersetztem Key.

verbatra.cache.json und .verbatra-local/ sind neu erzeugbarer, von git ignorierter Zustand; stell sie nie wieder her. Jede versionierte Datei wird atomar geschrieben, also gibt es nie eine halb geschriebene Datei zu reparieren.

Die Provenance-DateiLink zu diesem Abschnitt kopieren

Außerdem schreibt ein Lauf verbatra.provenance.json, das festhält, wer welchen Wert geschrieben hat. Stell sie zusammen mit den anderen beiden wieder her, oder lösch sie, wenn dieser Lauf sie angelegt hat. Sie zu vergessen ist nicht harmlos: Ein zurückgesetzter Wert passt nicht mehr zu seinem Eintrag, gilt also als external, zählt beim Standard humanEdits: protect als menschliche Änderung und wird nie wieder übersetzt.

Einen abgeschlossenen Lauf zurückrollenLink zu diesem Abschnitt kopieren

Ist der Lauf noch nicht committet, verwirf die Locale-Dateien und die Lock-Datei gemeinsam, danach die Herkunftsdatei:

git checkout HEAD -- locales verbatra.lock.json

Stell verbatra.provenance.json genauso wieder her, wenn sie schon committet ist. Hat dieser Lauf sie angelegt, hat git nichts wiederherzustellen, also lösch sie:

git checkout HEAD -- verbatra.provenance.json   # already committed
rm verbatra.provenance.json                      # created by this run

Ist der Lauf schon committet, mach den Commit rückgängig:

git revert <commit>

In beiden Fällen stellst du die Locale-Dateien, verbatra.lock.json und verbatra.provenance.json im selben Schritt wieder her. Der nächste Abschnitt erklärt, warum.

Warum alle drei Dateien oder keineLink zu diesem Abschnitt kopieren

Die Lock-Datei hält einen Hash des Quellwerts hinter jeder Übersetzung fest und nichts über den übersetzten Wert selbst; die Herkunftsdatei hält fest, wer jeden Wert geschrieben hat, verknüpft mit einem Hash dieses Werts. Setzt du eine Datei ohne die anderen zurück, beschreiben sie verschiedene Zeitpunkte.

Nur die Locale-Dateien. Die Lock-Datei sagt weiter, dass jeder Key aktuell ist. Beim nächsten Lauf ist ein zurückgesetzter Key vorhanden und sein Hash passt zur Quelle, also wird er nie wieder gesendet: Der alte Wert bleibt dauerhaft stehen. Nur Keys, die der Lauf neu angelegt hat, kommen als fehlend zurück. check und diff vergleichen mit derselben Baseline, melden die Locale also als sauber, und nichts sagt dir, dass diese Übersetzungen veraltet sind.

Nur die Lock-Datei. Die wiederhergestellten Hashes sind älter als die aktuelle Quelle, also gelten die betroffenen Keys als geändert. Der nächste Lauf übersetzt sie erneut und überschreibt die Locale-Dateien, samt Korrekturen von Hand, die seitdem gemacht wurden. Du zahlst doppelt und verlierst die Änderungen.

Ohne die Herkunftsdatei. Die zurückgesetzten Werte passen nicht mehr zu ihren Einträgen, gelten also als external und werden beim Standard humanEdits: protect nie wieder übersetzt.

Alle drei. Hashes, Einträge und Übersetzungen gehen auf denselben Zeitpunkt zurück, und der nächste Lauf verhält sich, als hätte es den missglückten Lauf nie gegeben.

Nach einem Rollback neu laufen lassenLink zu diesem Abschnitt kopieren

Zurückrollen und verbatra translate erneut ausführen ist eine Wiederholung, keine zweite Meinung. Mit gleichem Provider, Modell, Ton, den Glossarbegriffen, die verbatra senden würde, und Provider-localeMap bleibt der Cache-Fingerprint gleich, also liefert der Lauf dieselben Übersetzungen aus verbatra.cache.json, ohne den Provider aufzurufen.

Für ein anderes Ergebnis änderst du, was das erste falsch gemacht hat: Ein neuer Ton, ein neues Glossar oder ein anderes Modell ändert den Fingerprint und übersetzt von selbst neu. Um dieselbe Konfiguration erneut an den Provider zu schicken, nimm --no-cache dazu:

verbatra translate --no-cache

Um eine Locale von Grund auf neu aufzubauen, statt einen Lauf rückgängig zu machen, siehe Wie übersetze ich alles neu?. Die Lock-Datei zu löschen ist kein Zurücksetzen: Ohne Baseline wird nichts als veraltet erkannt, also übersetzt der nächste Lauf nichts.

Ein unterbrochener oder gescheiterter LaufLink zu diesem Abschnitt kopieren

Ein unterbrochener Lauf braucht kein Rollback. Führ ihn einfach erneut aus.

Jede Locale wird für sich abgeschlossen: Erst wird ihre Datei geschrieben, dann werden ihre Lock-Einträge erfasst. Eine Unterbrechung lässt die fertigen Locales vollständig und die anderen unberührt, und ein neuer Lauf nimmt die unberührten auf. Die eine Lücke, zwischen dem Schreiben der Datei und dem Lock-Update, schließt sich von selbst: Hinzugefügte Keys werden so übernommen, wie sie sind, und geänderte Keys tragen noch ihren alten Hash, also werden sie erneut übersetzt. Es geht keine Arbeit verloren.

Keys, die während eines Laufs zurückgehalten wurden, durch eine gescheiterte Prüfung, einen gescheiterten Provider-Aufruf oder ein Token-Budget, behalten ihren bisherigen Hash, also versucht der nächste Lauf sie erneut. Siehe Fehlerbehebung für jede Ursache.

Ein unterbrochener Lauf gibt seine Schreibsperren frei. Ein hart beendeter Prozess (kill -9, ein Absturz) kann eine unter .verbatra-local/ zurücklassen; der nächste Lauf auf derselben Maschine erkennt, dass der Prozess weg ist, und übernimmt sie. Eine Sperre, die er nicht prüfen kann, lässt den Lauf warten und dann mit LOCK_CONTENDED scheitern, das den zu löschenden Pfad nennt.

Vor einem Lauf, den du nicht leicht rückgängig machen kannstLink zu diesem Abschnitt kopieren

• Committe zuerst deine Locale-Dateien, verbatra.lock.json und verbatra.provenance.json, damit git checkout HEAD -- etwas hat, wohin es zurückkehren kann.
• Sieh dir vorab verbatra translate --dry-run, verbatra diff oder verbatra check an. Keiner davon ruft einen Provider auf oder schreibt eine Datei.
• Probier mit --locales <locale> zuerst eine Locale aus.

Siehe auchLink zu diesem Abschnitt kopieren

• Die Lock-Datei: was sie festhält und wie Abweichungen erkannt werden.
• Der Cache: der Fingerprint und --no-cache.
• verbatra translate: --dry-run, --locales und --no-cache.
• Fehlercodes: LOCK_CONTENDED und die anderen Sperrfehler.