---
title: "Einen Lauf rückgängig machen"
description: "Wie du einen translate-Lauf rückgängig machst, warum Locale-, Lock- und Herkunftsdatei zusammen zurückgesetzt werden und was ein abgebrochener Lauf hinterlässt."
type: "how-to"
---
# Einen Lauf rückgängig machen

Wie du einen translate-Lauf rückgängig machst, warum Locale-, Lock- und Herkunftsdatei zusammen zurückgesetzt werden und was ein abgebrochener Lauf hinterlässt.

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 schreibt [#was-ein-lauf-schreibt]

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-Datei [#die-provenance-datei]

<AvailableFrom version="0.12.0" />

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ückrollen [#einen-abgeschlossenen-lauf-zurückrollen]

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

```bash
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:

```bash
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:

```bash
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 keine [#warum-alle-drei-dateien-oder-keine]

Die Lock-Datei hält einen Hash des **Quell**werts 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 lassen [#nach-einem-rollback-neu-laufen-lassen]

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](https://verbatra.kreitz-webdev.de/de/docs/the-cache.md#der-fingerprint)-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:

```bash
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?](https://verbatra.kreitz-webdev.de/de/docs/faq.md#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 Lauf [#ein-unterbrochener-oder-gescheiterter-lauf]

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](https://verbatra.kreitz-webdev.de/de/docs/troubleshooting.md) 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`](https://verbatra.kreitz-webdev.de/de/docs/error-codes.md#lock_contended) scheitern, das den zu löschenden Pfad nennt.

## Vor einem Lauf, den du nicht leicht rückgängig machen kannst [#vor-einem-lauf-den-du-nicht-leicht-rückgängig-machen-kannst]

- 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 auch [#siehe-auch]

- [Die Lock-Datei](https://verbatra.kreitz-webdev.de/de/docs/the-lock-file.md): was sie festhält und wie Abweichungen erkannt werden.
- [Der Cache](https://verbatra.kreitz-webdev.de/de/docs/the-cache.md): der Fingerprint und `--no-cache`.
- [`verbatra translate`](https://verbatra.kreitz-webdev.de/de/docs/cli/translate.md): `--dry-run`, `--locales` und `--no-cache`.
- [Fehlercodes](https://verbatra.kreitz-webdev.de/de/docs/error-codes.md#lock_contended): `LOCK_CONTENDED` und die anderen Sperrfehler.