better-i18n Translation Version Control: Historial Completo y Rollback

El código de tu aplicación vive en Git. Cada cambio queda registrado. Cada línea tiene un autor conocido. Cualquier versión puede restaurarse en segundos. Si un commit incorrecto llega a producción, haces un Rollback. Si quieres entender por qué una función se escribió de cierta manera, lees el historial de commits.

Tus traducciones merecen el mismo tratamiento. Pero en la mayoría de las plataformas de localización, el historial es una idea de último momento — en el mejor caso, un registro de cambios básico, con búsqueda limitada, sin vista de diff y sin Rollback. Cuando algo sale mal con una traducción en producción, los equipos pasan horas tratando de descubrir qué cambió, cuándo y por qué, y luego más horas restaurando manualmente una versión anterior.

better-i18n trata Translation Version Control como una característica de primera clase. Cada cambio en cada string se registra con un diff completo, una marca de tiempo y la identidad del colaborador que realizó el cambio. El Rollback a cualquier versión anterior es un solo clic. El historial completo es consultable, buscable y está disponible a través de la API.

Cómo funciona

Versionado automático en cada guardado

Cada vez que se modifica un string de traducción en better-i18n — a través del editor web, a través de la herramienta CLI, a través de la integración MCP o a través de la API — se crea automáticamente una nueva versión. Las versiones se crean para cada idioma de forma independiente, por lo que cambiar la traducción alemana de un string crea una nueva versión del string alemán sin afectar la versión francesa.

Las versiones se crean independientemente de quién realizó el cambio. Traductores humanos, asistentes de IA que operan a través de la conexión MCP, scripts automatizados de actualización masiva usando la CLI — todos producen historial versionado. No hay manera de modificar una traducción sin dejar un registro.

Lo que registra cada versión

Cada registro de versión contiene:

Marca de tiempo: El momento exacto en que se creó la versión, en UTC.
Autor: La identidad del usuario o servicio que realizó el cambio. Para usuarios humanos, este es su nombre y perfil. Para operaciones de API o CLI, es el identificador del token de API.
Contenido antes y después: El texto completo de la traducción antes y después del cambio, lo que permite una vista de diff completa.
Transición de estado: Si el string pasó de un estado a otro (por ejemplo, de "en progreso" a "enviado para revisión", o de "aprobado" a "necesita revisión").
Nota de cambio: Un mensaje opcional adjuntado por el autor, similar a un mensaje de commit. El flujo de trabajo de colaboración anima a los autores a agregar notas de cambio cuando realizan correcciones basadas en los comentarios del revisor.
Resultados de verificación de QA: El estado de QA del string en el momento en que se creó la versión. Esto se obtiene del motor de aseguramiento de calidad y se almacena con la versión para referencia futura.

Ver el historial

El panel de historial de cualquier string muestra todas sus versiones en orden cronológico inverso. Cada entrada muestra el autor, la marca de tiempo, el estado en esa versión y un diff condensado del cambio de contenido (palabras agregadas resaltadas en verde, palabras eliminadas resaltadas en rojo).

Hacer clic en cualquier versión muestra el contenido completo en ese momento — no solo el diff, sino el string completo tal como existía cuando se creó esa versión.

El historial también es navegable a nivel de proyecto. Puedes ver una línea de tiempo de todos los cambios en todos los strings de un proyecto, filtrada por idioma, autor, rango de tiempo o cambio de estado. Esto es útil para auditorías, para revisiones post-incidente y para entender el ritmo y patrón general de la actividad de traducción.

Rollback

Revertir un string a una versión anterior es una sola acción. En el panel de historial, haz clic en "Restaurar esta versión" en cualquier entrada. El contenido actual se reemplaza con el contenido de la versión seleccionada. Se crea una nueva versión que registra el Rollback, incluida la versión que se restauró y quién realizó el Rollback.

El Rollback está disponible para Editores y Admins. Los Traductores y Revisores pueden ver el historial pero no pueden hacer Rollback, lo que previene la restauración accidental o no autorizada de contenido antiguo.

También puedes revertir un idioma completo a su estado en una marca de tiempo específica. Esto es útil cuando una operación masiva — una actualización de terminología, una traducción masiva asistida por IA — produce resultados inesperados en muchos strings. En lugar de revertir cada string individualmente, restauras todo el idioma a su estado previo a la operación y vuelves a intentar la operación con parámetros corregidos.

Comparar versiones

La vista de diff en better-i18n es a nivel de palabra, no a nivel de línea. Los strings de traducción son típicamente oraciones individuales o párrafos cortos. Un diff a nivel de línea a menudo mostraría el string completo como cambiado. Un diff a nivel de palabra muestra con precisión qué palabras se agregaron, eliminaron o reordenaron, lo que facilita mucho entender qué cambió realmente.

Puedes comparar cualquier dos versiones de un string — no solo versiones adyacentes. Selecciona dos puntos en el historial y ve el delta entre ellos, independientemente de cuántas versiones intermedias existan.

Etiquetado y snapshots de Release

Cuando despliegas una nueva versión de tu aplicación, puedes etiquetar el estado actual de tus traducciones con una etiqueta de release:

bi18n tag --name v2.5.0 --message "Release 2.5.0 translations"

Esto crea un snapshot de cada traducción en su estado aprobado actual. Luego puedes consultar el estado de cualquier string en cualquier etiqueta de release, comparar traducciones entre releases y restaurar strings individuales a su estado en un release anterior si es necesario.

Las etiquetas de release son visibles en el dashboard de analytics, que muestra métricas de cobertura y calidad vinculadas a cada release etiquetado.

Exportación de auditoría

Para industrias reguladas o requisitos de cumplimiento, el historial completo de cambios de un proyecto o un rango de tiempo específico puede exportarse como un archivo CSV o JSON estructurado. La exportación incluye cada registro de versión para cada string, en cada idioma, con contenido completo antes y después y datos de atribución.

Esta exportación es adecuada para adjuntar a informes de cumplimiento, para revisión de auditoría externa o para fines de archivo.

Beneficios clave

Responsabilidad completa

En un entorno de traducción en equipo, las cosas ocasionalmente salen mal. Un contratista sobrescribe un string cuidadosamente aprobado. Un script automatizado aplica un cambio de terminología que resulta incorrecto. Un revisor aprueba un string con un marcador de posición roto que se escapó.

Cuando cada cambio se registra con atribución y marcas de tiempo, siempre puedes responder la pregunta "¿qué pasó?". Sabes exactamente quién realizó el cambio, cuándo y cuál era el contenido antes del cambio. Esto es responsabilidad en el mismo sentido en que Git proporciona responsabilidad para los cambios de código.

Recuperación rápida de incidentes

Cuando un problema de traducción llega a producción — un marcador de posición roto que causa un error de JavaScript, un aviso legal mal traducido, un string completamente incorrecto — necesitas solucionarlo rápido. Sin Version Control, corregir una traducción incorrecta significa encontrar la versión antigua (que puede no existir en ningún lugar), restaurarla, volver a publicar y redesplegar.

Con better-i18n Version Control, la recuperación es: encontrar el string, abrir el historial, hacer clic en "Restaurar", publicar y activar un despliegue. Toda la operación lleva menos de dos minutos. La herramienta CLI puede obtener la traducción restaurada de inmediato para un despliegue rápido.

Operaciones masivas seguras

Las operaciones masivas — actualizaciones de terminología, traducciones masivas de IA, reemplazos de strings de rebranding — son poderosas pero arriesgadas. Si una operación masiva produce resultados incorrectos, necesitas una forma de deshacerla. Version Control de better-i18n hace que las operaciones masivas sean seguras al garantizar que cada string tocado por la operación tenga su estado anterior registrado y sea restaurable.

Antes de ejecutar cualquier operación masiva grande, puedes etiquetar el estado actual como punto de control de seguridad. Si la operación sale mal, restaura al punto de control.

Integración con Version Control de código

Translation Version Control en better-i18n está diseñado para complementar, no reemplazar, el Version Control basado en Git de tu codebase. Cuando etiquetas un release en better-i18n con el mismo número de versión que usas en Git, creas un enlace permanente entre el estado de tu código y el estado de tus traducciones en ese release. La depuración post-release se vuelve mucho más limpia cuando puedes correlacionar ambos.

La herramienta CLI admite la creación automática de etiquetas como parte de tu pipeline de despliegue, por lo que el enlace entre las versiones de código y traducción se mantiene sin esfuerzo manual.

Cumplimiento y preparación para auditorías

Para productos en industrias reguladas, demostrar el historial de cambios de contenido es a menudo un requisito de cumplimiento. Los productos de software de tecnología legal, fintech, atención médica y gobierno frecuentemente necesitan mostrar que su texto orientado al usuario — incluyendo versiones traducidas — fue revisado y aprobado por roles específicos en momentos específicos.

El historial de versiones de better-i18n proporciona esta evidencia de forma nativa. La exportación de auditoría produce un registro legible por máquina que puede enviarse a auditores o incorporarse a informes de cumplimiento.

Casos de uso

Respuesta a incidentes post-release: Un usuario alemán informa que un mensaje de confirmación de pago muestra un nombre de variable sin procesar en lugar del monto real. Buscas en el historial de versiones la traducción alemana del string de confirmación de pago, encuentras que fue modificado ayer por un script automatizado que accidentalmente eliminó un marcador de posición, lo revirtes a la última versión buena conocida y activas un redespliegue.

Revisión de rebranding: Tu empresa hace un rebranding y cambia un nombre clave de producto en todas las traducciones. Después de la actualización masiva, un stakeholder nota que el nuevo nombre se usa de manera inconsistente. Usas la vista de historial para comparar el estado actual con el snapshot previo al rebranding, identificas qué strings aún necesitan actualización y los corriges.

Auditoría de contratista: El contrato de un traductor externo está terminando. Antes de que pierdan acceso, exportas el historial completo de cambios para los idiomas que gestionaron. La exportación muestra cada string que crearon o modificaron, con marcas de tiempo y estado de QA, proporcionando un registro permanente de su contribución.

Retención legal: Tu equipo legal solicita un registro de todos los cambios realizados a los strings de traducción de términos de servicio en los últimos 12 meses. Filtras el historial por categoría de string y rango de tiempo y exportas el resultado como un informe listo para PDF.

Restauración de Translation Memory: Un nuevo traductor sobrescribe accidentalmente 40 strings aprobados mientras edita masivamente un idioma. Restauras todo el idioma a su estado de ayer por la tarde, recuperando todo el trabajo aprobado sin tener que retraduccir nada.

Cómo better-i18n implementa Version Control

Las versiones de traducción en better-i18n se almacenan como registros inmutables. Una vez que se escribe una versión, nunca se modifica. El Rollback no modifica los registros históricos — crea una nueva versión con el contenido restaurado. El historial es un log de solo adición.

El algoritmo de diff es un diff a nivel de palabra basado en el algoritmo de diff de Myers, adaptado para texto en lenguaje natural en lugar de código. Maneja la reestructuración de oraciones, el reordenamiento de palabras y los cambios parciales de palabras de una manera que hace que el diff sea legible para usuarios no técnicos.

El almacenamiento de versiones es eficiente. En lugar de almacenar el contenido completo de cada versión, el sistema almacena el contenido completo para la primera versión y diffs para versiones posteriores. El contenido completo se reconstruye al leer aplicando la cadena de diff. Este enfoque mantiene manejables los requisitos de almacenamiento para proyectos con historiales largos y muchos idiomas.

La API del historial de versiones admite paginación y filtrado, lo que hace práctico recuperar el historial de proyectos grandes de forma programática sin cargar todo el conjunto de datos a la vez.

Comparación con alternativas

Phrase Version History: Phrase almacena el historial de versiones pero con capacidades de Rollback limitadas. Revertir requiere la reintroducción manual del contenido anterior en lugar de una restauración con un clic. better-i18n proporciona verdadero Rollback con un clic con comparación de diff completa.

Lokalise Version Control: Lokalise incluye historial de cambios por string, pero el Rollback masivo a nivel de idioma no está disponible. better-i18n admite Rollback tanto a nivel de string como a nivel de idioma.

Archivos de traducción gestionados con Git: Almacenar archivos de traducción en Git te da historial completo y Rollback a través de comandos de Git, pero excluye a los miembros no técnicos del equipo de contribuir y revisar. Los conflictos de merge en archivos JSON son propensos a errores. better-i18n te da los beneficios de Version Control de Git con un flujo de trabajo accesible para todos.

Sin Version Control: Muchas plataformas de localización e implementaciones personalizadas no tienen historial de versiones significativo. Cuando algo sale mal, la recuperación es manual y consume tiempo. Este es el status quo que better-i18n está diseñado para reemplazar.

Preguntas frecuentes

¿Cuánto tiempo se retiene el historial de versiones? El historial de versiones se retiene indefinidamente en todos los planes. No hay poda automática de versiones antiguas.

¿Puedo restaurar una versión muy antigua — de años atrás? Sí. Cualquier versión en el historial puede restaurarse independientemente de su antigüedad. El contenido restaurado se convierte en la versión actual y se crea un nuevo registro de versión documentando la restauración.

¿El Rollback afecta a los strings publicados? El Rollback restaura el contenido y el estado de un string a su estado en la versión seleccionada. Si la versión seleccionada tenía estado "aprobado", el string de Rollback tiene estado "aprobado" y puede publicarse. El Rollback no publica nada automáticamente — todavía se requiere un paso de publicación.

¿Es la exportación de auditoría admisible para fines de cumplimiento? La exportación de auditoría proporciona un registro completo con marcas de tiempo de todos los cambios con atribución. Si esto es suficiente para un marco de cumplimiento específico depende de los requisitos del marco. Recomendamos consultar con tu equipo de cumplimiento sobre qué nivel de documentación se requiere.

¿Puedo ver el historial de un string que ha sido eliminado? Sí. Los strings eliminados y su historial se retienen en un estado archivado. Puedes buscar strings eliminados y ver su historial completo. Los strings eliminados no pueden restaurarse al estado activo sin recrear la clave del string.

Nunca pierdas una traducción de nuevo

Version Control para traducciones no es un lujo — es un requisito de seguridad para cualquier equipo que tome la localización en serio. better-i18n registra cada cambio, hace el historial visible y buscable, y permite el Rollback instantáneo cuando algo sale mal.

Comienza tu prueba gratuita y ve el historial completo de tus traducciones desde el primer día.

better-i18n Translation Version Control: Historial Completo y Rollback