---
title: "Deshaz una ejecución"
description: "Cómo deshacer una ejecución de translate, por qué los archivos de locale, de bloqueo y de procedencia se revierten juntos y qué deja una ejecución interrumpida."
type: "how-to"
---
# Deshaz una ejecución

Cómo deshacer una ejecución de translate, por qué los archivos de locale, de bloqueo y de procedencia se revierten juntos y qué deja una ejecución interrumpida.

Usa esto cuando una ejecución produjo traducciones que no quieres: el tono equivocado, el modelo equivocado, un glosario que olvidaste. verbatra no tiene comando de deshacer ni guarda copias de seguridad. El control de versiones es el mecanismo de recuperación, y por eso se confirman los archivos de locale, el archivo de bloqueo y el archivo de procedencia: juntos son la instantánea a la que vuelves.

Necesitas el proyecto en git, con el estado anterior a la ejecución confirmado.

## Qué escribe una ejecución [#qué-escribe-una-ejecución]

Una ejecución de `translate`, `watch` o `import` escribe los archivos que le importan a una reversión:

- los archivos de locale de destino, en tu ruta `files.pattern`;
- `verbatra.lock.json`, un hash del contenido de origen por cada clave traducida.

`verbatra.cache.json` y `.verbatra-local/` son estado regenerable e ignorado por git; no los restaures nunca. Cada archivo versionado se escribe de forma atómica, así que nunca hay un archivo a medio escribir que reparar.

### El archivo de procedencia [#el-archivo-de-procedencia]

<AvailableFrom version="0.12.0" />

Una ejecución también escribe `verbatra.provenance.json`, que registra quién escribió cada valor. Restáuralo junto con los otros dos, o bórralo si lo creó esta ejecución. Olvidarlo no es inocuo: un valor revertido ya no coincide con su registro, así que se lee como `external`, cuenta como edición humana con el valor por defecto `humanEdits: protect` y nunca se vuelve a traducir.

## Revertir una ejecución terminada [#revertir-una-ejecución-terminada]

Si la ejecución aún no está confirmada, descarta los archivos de locale y el archivo de bloqueo juntos, y después el archivo de procedencia:

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

Restaura `verbatra.provenance.json` del mismo modo si ya está confirmado. Si lo creó esta ejecución, git no tiene nada que restaurar, así que bórralo:

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

Si la ejecución ya está confirmada, revierte ese commit:

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

En ambos casos, restaura los archivos de locale, `verbatra.lock.json` y `verbatra.provenance.json` en la misma operación. La siguiente sección explica por qué.

## Por qué los tres archivos o ninguno [#por-qué-los-tres-archivos-o-ninguno]

El archivo de bloqueo registra un hash del valor de **origen** detrás de cada traducción, y nada sobre el valor traducido; el archivo de procedencia registra quién escribió cada valor, ligado a un hash de ese valor. Si reviertes un archivo sin los otros, describen momentos distintos.

**Solo los archivos de locale.** El archivo de bloqueo sigue diciendo que todas las claves están al día. En la siguiente ejecución, una clave restaurada está presente y su hash coincide con el origen, así que nunca se vuelve a enviar: el valor antiguo se queda para siempre. Solo las claves que la ejecución creó vuelven como faltantes. `check` y `diff` comparan con la misma referencia, así que informan del locale como limpio, y nada te dice que esas traducciones están desactualizadas.

**Solo el archivo de bloqueo.** Los hashes restaurados son más antiguos que el origen actual, así que las claves afectadas se leen como cambiadas. La siguiente ejecución las vuelve a traducir y sobrescribe los archivos de locale, incluidas las correcciones a mano hechas desde entonces. Pagas dos veces y pierdes las ediciones.

**Sin el archivo de procedencia.** Los valores revertidos ya no coinciden con sus registros, así que se leen como `external` y, con el valor por defecto `humanEdits: protect`, nunca se vuelven a traducir.

**Los tres.** Los hashes, los registros y las traducciones vuelven al mismo momento, y la siguiente ejecución se comporta como si la ejecución fallida nunca hubiera ocurrido.

## Vuelve a ejecutar tras una reversión [#vuelve-a-ejecutar-tras-una-reversión]

Revertir y volver a ejecutar `verbatra translate` es repetir, no pedir una segunda opinión. Con el mismo proveedor, modelo, tono, los términos del glosario que verbatra enviaría y `localeMap` del proveedor, la huella de la [caché](https://verbatra.kreitz-webdev.de/es/docs/the-cache.md#la-huella) no cambia, así que la ejecución sirve las mismas traducciones desde `verbatra.cache.json` sin llamar al proveedor.

Para obtener otro resultado, cambia lo que hizo mal el primero: un tono, un glosario o un modelo nuevos cambian la huella y vuelven a traducir por sí solos. Para reenviar la misma configuración al proveedor, añade `--no-cache`:

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

Para reconstruir un locale desde cero en lugar de deshacer una ejecución, consulta [¿Cómo lo retraduzco todo?](https://verbatra.kreitz-webdev.de/es/docs/faq.md#cómo-lo-retraduzco-todo). Borrar el archivo de bloqueo no es un reinicio: sin referencia no se detecta nada como desactualizado, así que la siguiente ejecución no traduce nada.

## Una ejecución interrumpida o fallida [#una-ejecución-interrumpida-o-fallida]

Una ejecución interrumpida no necesita reversión. Vuelve a ejecutarla.

Cada locale se cierra por separado: primero se escribe su archivo y luego se registran sus entradas de bloqueo. Una interrupción deja completos los locales terminados y sin tocar los demás, y una nueva ejecución recoge los que no se tocaron. El único hueco, entre escribir el archivo de un locale y actualizar su bloqueo, se resuelve solo: las claves añadidas se adoptan tal como están, y las claves cambiadas aún llevan su hash antiguo, así que se vuelven a traducir. No se pierde trabajo.

Las claves retenidas durante una ejecución, por una comprobación fallida, una llamada al proveedor fallida o un presupuesto de tokens, conservan su hash anterior, así que la siguiente ejecución las reintenta. Consulta [Solución de problemas](https://verbatra.kreitz-webdev.de/es/docs/troubleshooting.md) para cada causa.

Una ejecución interrumpida libera sus bloqueos de escritura. Un proceso terminado a la fuerza (`kill -9`, un fallo) puede dejar uno en `.verbatra-local/`; la siguiente ejecución en la misma máquina ve que el proceso ya no existe y lo recupera. Un bloqueo que no puede comprobar hace que la ejecución espere y luego falle con [`LOCK_CONTENDED`](https://verbatra.kreitz-webdev.de/es/docs/error-codes.md#lock_contended), que nombra la ruta que hay que borrar.

## Antes de una ejecución que no puedes deshacer fácilmente [#antes-de-una-ejecución-que-no-puedes-deshacer-fácilmente]

- Confirma primero tus archivos de locale, `verbatra.lock.json` y `verbatra.provenance.json`, para que `git checkout HEAD --` tenga adónde volver.
- Previsualiza con `verbatra translate --dry-run`, `verbatra diff` o `verbatra check`. Ninguno llama a un proveedor ni escribe un archivo.
- Prueba primero un locale con `--locales <locale>`.

## Relacionado [#relacionado]

- [El archivo de bloqueo](https://verbatra.kreitz-webdev.de/es/docs/the-lock-file.md): qué registra y cómo se detectan las desviaciones.
- [La caché](https://verbatra.kreitz-webdev.de/es/docs/the-cache.md): la huella y `--no-cache`.
- [`verbatra translate`](https://verbatra.kreitz-webdev.de/es/docs/cli/translate.md): `--dry-run`, `--locales` y `--no-cache`.
- [Códigos de error](https://verbatra.kreitz-webdev.de/es/docs/error-codes.md#lock_contended): `LOCK_CONTENDED` y los demás errores de bloqueo.