Skip to main content
Branches let you work on an isolated copy of a project’s translations without affecting the main line — then review the differences and merge them back. If you’ve used Git, the model will feel familiar.
Over the API. Every read/write endpoint accepts ?branch=<branchId> to target a branch instead of main, plus endpoints to create, merge, and resolve conflicts. See Branch targeting in the API Reference.

​
Why use branches

  • Feature work — translate copy for an upcoming feature (e.g. feature/gift-cards) without it leaking into production exports.
  • Large reworks — restructure or retranslate a big section safely, then merge when it’s reviewed.
  • Experiments — try alternative wording and compare before committing.

​
What a branch contains

A branch starts as a snapshot of the project’s main translations. On it you can:
  • Add new keys that exist only on the branch.
  • Override values — change a key’s translation on the branch while main keeps its own value.
Until you merge, none of this affects the main line or its exports.

​
Enabling branching

Branching is off by default. Turn on Enable branching in the project’s Settings → Branching card; the Branches tab then appears in the project. You can also Protect main (block direct edits to main) and Require approval for merge.
Disabling branching deletes every branch. If you later turn branching off, all branches and their changes are permanently deleted (you’re asked to confirm first). Merge or export anything you want to keep beforehand.

​
Working with branches

  • Create a branch — give it a name (e.g. feature/gift-cards). It branches from the current state of main.
  • Switch branches — use the branch selector; a banner shows which branch you’re currently editing so you always know your context.
  • Edit on the branch — translate and add keys exactly as you would on main.

​
Reviewing the diff

Open the branch diff to see exactly what changed versus main:
  • New keys added on the branch.
  • Overridden values that differ from main.
Review the diff before merging so there are no surprises.

​
Merging

When the branch is ready, merge it into main. New keys are added to main, and overridden values are applied. After merging, the changes become part of the main line and appear in normal exports.

​
Tips

  • Name branches after the work they hold (feature/..., rework/...) so the branch list stays readable.
  • Review the diff before every merge.
  • Combine branches with the approval workflow for an extra gate on large changes.
Related: Translating · History & Rollback