Annuler une exécution

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écutionCopier le lien vers cette section

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 provenanceCopier le lien vers cette section

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éeCopier le lien vers cette section

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 :

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 :

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 :

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 aucunCopier le lien vers cette section

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èreCopier le lien vers cette section

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

verbatra translate --no-cache

Pour reconstruire une locale de zéro plutôt qu'annuler une exécution, voir 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 échecCopier le lien vers cette section

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 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, qui nomme le chemin à supprimer.

Avant une exécution difficile à annulerCopier le lien vers cette section

• 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 aussiCopier le lien vers cette section

• Le fichier de verrouillage : ce qu'il enregistre et comment les écarts sont détectés.
• Le cache : l'empreinte et --no-cache.
• verbatra translate : --dry-run, --locales et --no-cache.
• Codes d'erreur : LOCK_CONTENDED et les autres erreurs de verrou.