---
title: "Annuler une exécution"
description: "Annule une exécution de translate, restaure ensemble les fichiers de locale, de verrouillage et de provenance, et vois ce que laisse une interruption."
type: "how-to"
---
# Annuler une exécution

Annule une exécution de translate, restaure ensemble les fichiers de locale, de verrouillage et de provenance, et vois ce que laisse une interruption.

Utilise ceci quand une exécution a produit des traductions dont tu ne veux pas : le mauvais ton, le mauvais modèle, un glossaire oublié. verbatra n'a pas de commande d'annulation et ne garde aucune sauvegarde. Le contrôle de version est le mécanisme de récupération, et c'est pour ça que les fichiers de locale, le fichier de verrouillage et le fichier de provenance sont commités : ensemble, ils forment l'instantané vers lequel tu reviens.

Il te faut le projet dans git, avec l'état d'avant l'exécution commité.

## Ce qu'écrit une exécution [#ce-quécrit-une-exécution]

Une exécution de `translate`, `watch` ou `import` écrit les fichiers dont un retour arrière doit s'occuper :

- les fichiers de locale cibles, au chemin de ton `files.pattern` ;
- `verbatra.lock.json`, un hash du contenu source par clé traduite.

`verbatra.cache.json` et `.verbatra-local/` sont un état régénérable, ignoré par git ; ne les restaure jamais. Chaque fichier suivi est écrit de façon atomique, il n'y a donc jamais de fichier à moitié écrit à réparer.

### Le fichier de provenance [#le-fichier-de-provenance]

<AvailableFrom version="0.12.0" />

Une exécution écrit aussi `verbatra.provenance.json`, qui enregistre qui a écrit chaque valeur. Restaure-le avec les deux autres, ou supprime-le si cette exécution l'a créé. L'oublier n'est pas anodin : une valeur restaurée ne correspond plus à son enregistrement, donc elle se lit comme `external`, compte comme une modification humaine avec la valeur par défaut `humanEdits: protect` et n'est plus jamais traduite.

## Annuler une exécution terminée [#annuler-une-exécution-terminée]

Si l'exécution n'est pas encore commitée, jette ensemble les fichiers de locale et le fichier de verrouillage, puis le fichier de provenance :

```bash
git checkout HEAD -- locales verbatra.lock.json
```

Restaure `verbatra.provenance.json` de la même façon s'il est déjà commité. Si c'est cette exécution qui l'a créé, git n'a rien à restaurer, alors supprime-le :

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

Si l'exécution est déjà commitée, annule ce commit :

```bash
git revert <commit>
```

Dans les deux cas, restaure les fichiers de locale, `verbatra.lock.json` et `verbatra.provenance.json` dans la même opération. La section suivante explique pourquoi.

## Pourquoi les trois fichiers ou aucun [#pourquoi-les-trois-fichiers-ou-aucun]

Le fichier de verrouillage enregistre un hash de la valeur **source** derrière chaque traduction, et rien sur la valeur traduite elle-même ; le fichier de provenance enregistre qui a écrit chaque valeur, lié à un hash de cette valeur. Si tu restaures un fichier sans les autres, ils décrivent des moments différents.

**Seulement les fichiers de locale.** Le fichier de verrouillage dit toujours que chaque clé est à jour. À l'exécution suivante, une clé restaurée est présente et son hash correspond à la source, elle n'est donc jamais renvoyée : l'ancienne valeur reste en place pour de bon. Seules les clés que l'exécution a créées reviennent comme manquantes. `check` et `diff` comparent avec la même référence, ils signalent donc la locale comme propre, et rien ne te dit que ces traductions sont périmées.

**Seulement le fichier de verrouillage.** Les hashes restaurés sont plus anciens que la source actuelle, donc les clés concernées apparaissent comme modifiées. L'exécution suivante les retraduit et écrase les fichiers de locale, y compris les corrections faites à la main depuis. Tu paies deux fois et tu perds les modifications.

**Sans le fichier de provenance.** Les valeurs restaurées ne correspondent plus à leurs enregistrements, elles se lisent donc comme `external` et, avec la valeur par défaut `humanEdits: protect`, ne sont plus jamais traduites.

**Les trois.** Les hashes, les enregistrements et les traductions reviennent au même moment, et l'exécution suivante se comporte comme si la mauvaise exécution n'avait jamais eu lieu.

## Relancer après un retour arrière [#relancer-après-un-retour-arrière]

Revenir en arrière puis relancer `verbatra translate` refait la même chose, ce n'est pas un second avis. Avec le même fournisseur, le même modèle, le même ton, les termes du glossaire que verbatra enverrait et la même `localeMap` du fournisseur, l'empreinte du [cache](https://verbatra.kreitz-webdev.de/fr/docs/the-cache.md#lempreinte) ne change pas, donc l'exécution ressert les mêmes traductions depuis `verbatra.cache.json` sans appeler le fournisseur.

Pour obtenir un autre résultat, change ce qui a rendu le premier mauvais : un nouveau ton, un nouveau glossaire ou un autre modèle change l'empreinte et retraduit tout seul. Pour renvoyer la même configuration au fournisseur, ajoute `--no-cache` :

```bash
verbatra translate --no-cache
```

Pour reconstruire une locale de zéro plutôt qu'annuler une exécution, voir [Comment je retraduis tout ?](https://verbatra.kreitz-webdev.de/fr/docs/faq.md#comment-je-retraduis-tout-). Supprimer le fichier de verrouillage n'est pas une remise à zéro : sans référence, rien n'est détecté comme obsolète, donc l'exécution suivante ne traduit rien.

## Une exécution interrompue ou en échec [#une-exécution-interrompue-ou-en-échec]

Une exécution interrompue n'a pas besoin de retour arrière. Relance-la.

Chaque locale est finalisée séparément : son fichier est écrit, puis ses entrées de verrouillage sont enregistrées. Une interruption laisse complètes les locales terminées et intactes les autres, et une nouvelle exécution reprend celles qui n'ont pas été touchées. Le seul écart, entre l'écriture du fichier d'une locale et la mise à jour de son verrouillage, se résout tout seul : les clés ajoutées sont adoptées telles quelles, et les clés modifiées portent encore leur ancien hash, elles sont donc retraduites. Aucun travail n'est perdu.

Les clés retenues pendant une exécution, par un contrôle échoué, un appel au fournisseur échoué ou un budget de tokens, gardent leur hash précédent, donc l'exécution suivante les réessaie. Voir [Dépannage](https://verbatra.kreitz-webdev.de/fr/docs/troubleshooting.md) pour chaque cause.

Une exécution interrompue libère ses verrous d'écriture. Un processus tué brutalement (`kill -9`, un plantage) peut en laisser un sous `.verbatra-local/` ; l'exécution suivante sur la même machine voit que le processus a disparu et le récupère. Un verrou qu'elle ne peut pas vérifier la fait attendre puis échouer avec [`LOCK_CONTENDED`](https://verbatra.kreitz-webdev.de/fr/docs/error-codes.md#lock_contended), qui nomme le chemin à supprimer.

## Avant une exécution difficile à annuler [#avant-une-exécution-difficile-à-annuler]

- Commite d'abord tes fichiers de locale, `verbatra.lock.json` et `verbatra.provenance.json`, pour que `git checkout HEAD --` ait un point de retour.
- Prévisualise avec `verbatra translate --dry-run`, `verbatra diff` ou `verbatra check`. Aucun n'appelle de fournisseur ni n'écrit de fichier.
- Essaie d'abord une seule locale avec `--locales <locale>`.

## Voir aussi [#voir-aussi]

- [Le fichier de verrouillage](https://verbatra.kreitz-webdev.de/fr/docs/the-lock-file.md) : ce qu'il enregistre et comment les écarts sont détectés.
- [Le cache](https://verbatra.kreitz-webdev.de/fr/docs/the-cache.md) : l'empreinte et `--no-cache`.
- [`verbatra translate`](https://verbatra.kreitz-webdev.de/fr/docs/cli/translate.md) : `--dry-run`, `--locales` et `--no-cache`.
- [Codes d'erreur](https://verbatra.kreitz-webdev.de/fr/docs/error-codes.md#lock_contended) : `LOCK_CONTENDED` et les autres erreurs de verrou.