Translation Version Control: Full History & Rollback

Translation Version Control: Full History & Rollback

Your application code lives in Git. Every change is tracked. Every line has a known author. Every version can be restored in seconds. If a bad commit goes to production, you roll back. If you want to know why a function was written a certain way, you read the commit history.

Your translations deserve the same treatment. But in most localization platforms, history is an afterthought — a basic changelog at best, with limited search, no diff view, and no rollback. When something goes wrong with a translation in production, teams spend hours trying to figure out what changed, when, and why, and then more hours manually restoring a previous version.

better-i18n treats translation version control as a first-class feature. Every change to every string is recorded with a full diff, a timestamp, and the identity of the contributor who made the change. Rollback to any previous version is a single click. The full history is queryable, searchable, and available via the API.

How It Works

Automatic Versioning on Every Save

Every time a translation string is modified in better-i18n — through the web editor, through the CLI tool, through the MCP integration, or through the API — a new version is automatically created. Versions are created for every language independently, so changing the German translation of a string creates a new version of the German string without affecting the French version.

Versions are created regardless of who made the change. Human translators, AI assistants operating through the MCP connection, automated bulk update scripts using the CLI — all of them produce versioned history. There is no way to modify a translation without leaving a record.

What Each Version Records

Each version record contains:

• Timestamp: The exact time the version was created, in UTC.
• Author: The identity of the user or service that made the change. For human users, this is their name and profile. For API or CLI operations, it is the API token identifier.
• Before and after content: The full text of the translation before and after the change, enabling a complete diff view.
• Status transition: Whether the string moved from one status to another (e.g., "in progress" to "submitted for review", or "approved" to "needs revision").
• Change note: An optional message attached by the author, similar to a commit message. The collaboration workflow encourages authors to add change notes when making corrections based on reviewer feedback.
• QA check results: The QA status of the string at the time the version was created. This is pulled from the quality assurance engine and stored with the version for later reference.

Viewing History

The history panel for any string shows all its versions in reverse chronological order. Each entry shows the author, the timestamp, the status at that version, and a condensed diff of the content change (words added highlighted in green, words removed highlighted in red).

Clicking on any version shows the full content at that point in time — not just the diff, but the complete string as it existed when that version was created.

History is also browsable at the project level. You can view a timeline of all changes across all strings in a project, filtered by language, by author, by time range, or by status change. This is useful for audits, for post-incident reviews, and for understanding the overall pace and pattern of translation activity.

Rollback

Rolling back a string to a previous version is a single action. In the history panel, click "Restore this version" on any entry. The current content is replaced with the content from the selected version. A new version is created recording the rollback, including which version was restored and who performed the rollback.

Rollback is available to Editors and Admins. Translators and Reviewers can view history but cannot roll back, preventing accidental or unauthorized restoration of old content.

You can also roll back an entire language to its state at a specific timestamp. This is useful when a bulk operation — a terminology update, an AI-assisted mass translation — produces unexpected results across many strings. Rather than rolling back each string individually, you restore the entire language to its pre-operation state and retry the operation with corrected parameters.

Comparing Versions

The diff view in better-i18n is word-level, not line-level. Translation strings are typically single sentences or short paragraphs. A line-level diff would often show the entire string as changed. A word-level diff shows precisely which words were added, removed, or rearranged, making it much easier to understand what was actually changed.

You can compare any two versions of a string — not just adjacent versions. Select two points in the history and see the delta between them, regardless of how many intermediate versions exist.

Tagging and Release Snapshots

When you deploy a new version of your application, you can tag the current state of your translations with a release label:

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

This creates a snapshot of every translation in its current approved state. You can later query the state of any string at any release tag, compare translations between releases, and restore individual strings to their state at a past release if needed.

Release tags are visible in the analytics dashboard, which shows coverage and quality metrics tied to each tagged release.

Audit Export

For regulated industries or compliance requirements, the full change history for a project or a specific time range can be exported as a structured CSV or JSON file. The export includes every version record for every string, in every language, with full before-and-after content and attribution data.

This export is suitable for attaching to compliance reports, for external audit review, or for archival purposes.

Key Benefits

Complete Accountability

In a team translation environment, things occasionally go wrong. A contractor overwrites a carefully approved string. An automated script applies a terminology change that turns out to be incorrect. A reviewer approves a string with a broken placeholder that slipped through.

When every change is recorded with attribution and timestamps, you can always answer the question "what happened?". You know exactly who made the change, when, and what the content was before the change. This is accountability in the same sense that Git provides accountability for code changes.

Fast Incident Recovery

When a translation problem reaches production — a broken placeholder that causes a JavaScript error, a mistranslated legal disclaimer, a string that is completely wrong — you need to fix it fast. Without version control, fixing a bad translation means finding the old version (which may not exist anywhere), restoring it, re-publishing, and redeploying.

With better-i18n version control, recovery is: find the string, open history, click "Restore", publish, and trigger a deploy. The entire operation takes under two minutes. The CLI tool can pull the restored translation immediately for a fast deployment.

Safe Bulk Operations

Bulk operations — terminology updates, mass AI translations, rebrand string replacements — are powerful but risky. If a bulk operation produces incorrect results, you need a way to undo it. better-i18n's version control makes bulk operations safe by ensuring that every string touched by the operation has its previous state recorded and is restorable.

Before running any large bulk operation, you can tag the current state as a safety checkpoint. If the operation goes wrong, restore to the checkpoint.

Integration with Code Version Control

Translation version control in better-i18n is designed to complement, not replace, Git-based version control of your codebase. When you tag a release in better-i18n with the same version number you use in Git, you create a permanent link between the state of your code and the state of your translations at that release. Post-release debugging becomes much cleaner when you can correlate both.

The CLI tool supports creating tags automatically as part of your deployment pipeline, so the link between code and translation versions is maintained without manual effort.

Compliance and Audit Readiness

For products in regulated industries, demonstrating the history of content changes is often a compliance requirement. Legal tech, fintech, healthcare, and government software products frequently need to show that their user-facing text — including translated versions — was reviewed and approved by specific roles at specific times.

better-i18n's version history provides this evidence out of the box. The audit export produces a machine-readable record that can be submitted to auditors or incorporated into compliance reports.

Use Cases

Post-Release Incident Response: A German user reports that a payment confirmation message is displaying a raw variable name instead of the actual amount. You search the version history for the German translation of the payment confirmation string, find that it was modified yesterday by an automated script that accidentally removed a placeholder, roll it back to the last known good version, and trigger a redeploy.

Rebrand Review: Your company rebrands and changes a key product name across all translations. After the bulk update, a stakeholder notices that the new name is being used inconsistently. You use the history view to compare the current state with the pre-rebrand snapshot, identify which strings still need updating, and fix them.

Contractor Audit: An external translation contractor's contract is ending. Before they lose access, you export the full change history for the languages they managed. The export shows every string they created or modified, with timestamps and QA status, providing a permanent record of their contribution.

Legal Hold: Your legal team requests a record of all changes made to terms-of-service translation strings in the past 12 months. You filter the history by string category and time range and export the result as a PDF-ready report.

Translation Memory Restoration: A new translator accidentally overwrites 40 approved strings while bulk-editing a language. You restore the entire language to its state from yesterday afternoon, recovering all the approved work without having to re-translate anything.

How better-i18n Implements Version Control

Translation versions in better-i18n are stored as immutable records. Once a version is written, it is never modified. Rollback does not modify historical records — it creates a new version with the restored content. The history is an append-only log.

The diff algorithm is a word-level diff based on the Myers diff algorithm, adapted for natural language text rather than code. It handles sentence restructuring, word reordering, and partial word changes in a way that makes the diff readable to non-technical users.

Version storage is efficient. Rather than storing the full content of every version, the system stores full content for the first version and diffs for subsequent versions. Full content is reconstructed on read by applying the diff chain. This approach keeps storage requirements manageable for projects with long histories and many languages.

The version history API supports pagination and filtering, making it practical to retrieve history for large projects programmatically without loading the entire dataset at once.

Comparison with Alternatives

Phrase Version History: Phrase stores version history but with limited rollback capabilities. Rolling back requires manual re-entry of the previous content rather than a one-click restore. better-i18n provides true one-click rollback with full diff comparison.

Lokalise Version Control: Lokalise includes change history per string, but bulk language-level rollback is not available. better-i18n supports both string-level and language-level rollback.

Git-Managed Translation Files: Storing translation files in Git gives you full history and rollback via Git commands, but it excludes non-technical team members from contributing and reviewing. Merge conflicts in JSON files are error-prone. better-i18n gives you the version control benefits of Git with a workflow accessible to everyone.

No Version Control: Many localization platforms and custom implementations have no meaningful version history. When something goes wrong, recovery is manual and time-consuming. This is the status quo that better-i18n is designed to replace.

Frequently Asked Questions

How long is version history retained? Version history is retained indefinitely on all plans. There is no automatic pruning of old versions.

Can I restore a version that is very old — years old? Yes. Any version in the history can be restored regardless of age. The restored content becomes the current version, and a new version record is created documenting the restoration.

Does rollback affect published strings? Rollback restores the content and status of a string to its state at the selected version. If the selected version had "approved" status, the rollback string has "approved" status and can be published. If it had "in progress" status, the rollback string has "in progress" status. The rollback does not automatically publish anything — a publish step is still required.

Is the audit export admissible for compliance purposes? The audit export provides a complete, timestamped record of all changes with attribution. Whether this is sufficient for a specific compliance framework depends on the framework requirements. We recommend consulting with your compliance team about what level of documentation is required.

Can I view the history of a string that has since been deleted? Yes. Deleted strings and their history are retained in an archived state. You can search for deleted strings and view their full history. Deleted strings cannot be restored to active status without re-creating the string key.

Never Lose a Translation Again

Version control for translations is not a luxury — it is a safety requirement for any team that takes localization seriously. better-i18n records every change, makes the history visible and searchable, and enables instant rollback when things go wrong.

Start your free trial and see the full history of your translations from day one.