Translatize vs Lokalise

Lokalise is one of the best-established translation management platforms in the category, with a large customer base and years of accumulated product polish. Translatize is a newer, narrower tool built around one idea: translations should branch and merge the way code does.

This is written by the Translatize team, and it compares the two on a specific set of dimensions – the branching and merge model, file format coverage, the developer automation story, roles and permissions, and the shape of each pricing model. Both products do more than this list. For a vendor-neutral read of the wider market, including capabilities not covered here, see Lokalise vs Crowdin vs Phrase.

The short version

Both tools store keys, hold translations per language, support branches, and give you an API and a CLI to move strings in and out. The difference this article is about is how central branching is to each, how many file formats survive a round trip, and what a merge into main is allowed to do.

If translations live in your repo, change on feature branches, and you want the state of feature/checkout-v2 to be as isolated – and as mergeable – as the code that uses it, the sections below are the ones worth your time.

Branching is the data model

Lokalise supports branching too – this is not a "they don't have it" claim. The difference is architectural. In Translatize, a branch is the unit everything else hangs off: labels belong to a branch, API tokens are bound to a branch, webhooks cover label and branch events, and merging is a first-class operation with explicit, named strategies rather than a single behaviour.

Four merge strategies

When you merge a branch into another, you choose how conflicts resolve:

manual is the one that matters for teams with review discipline: you get a flat list of conflicting keys with both candidate values, and nothing is written until you decide.

Permission-guarded merges

Roles are per project – owner, admin, developer, translator – and branch operations are gated by role level. Developers and above can create branches. Only the branch's creator or an admin can delete one. Only an admin or the owner can merge into main. That means a translator can be given a feature branch to work in without any path to modifying production strings, which is the same guarantee a protected branch gives you in git.

File formats and round-tripping

Translatize imports and exports nine formats. Three of them carry every language in a single file; the rest are one file per language, which matters when you script the pull side.

XLIFF being bilingual is the useful detail for agency handoff: each unit ships with its source text, so an external translator has the context without needing access to your project. Lokalise's format list is longer and covers more exotic cases; if you have a format that isn't in the table above – Windows .resw variants, subtitle files, spreadsheet-driven marketing copy – check Lokalise's docs before assuming parity.

The developer loop

Translatize's automation runs on integration tokens prefixed mcni_, each bound to a single project and branch. A token can't wander into another project, and a standard token can't touch a branch other than its own. The CLI reads it from the environment:

npm install -D @translatize/cli
export TRANSLATIZE_API_TOKEN=mcni_xxx

npx translatize init          # writes translatize.config.json
npx translatize pull          # writes locales/<lang>.json per language

The config file is committed; the token never is:

{
  "apiUrl": "https://api.translatize.com/v1",
  "projectId": "your-project-id",
  "format": "json-nested",
  "files": "locales/{lang}.json",
  "branch": "feature/checkout-v2"
}

The files value must contain the {lang} placeholder. format picks whether dotted keys like app.nav.home are written nested or left flat.

The CI gate is status, which compares local files against the branch and can fail the build:

- name: Check translation completeness
  run: npx translatize status --branch "$GITHUB_HEAD_REF" --fail-on-missing
  env:
    TRANSLATIZE_API_TOKEN: ${{ secrets.TRANSLATIZE_API_TOKEN }}

push uploads only new and changed keys and never deletes remote keys – keys that exist on the branch but not locally are reported and left alone. Alongside the CLI there is a @translatize/core SDK, a @translatize/mcp MCP server so an AI coding agent can read and write keys directly, and GitHub Action and GitLab CI templates. Full details are in the docs.

Both vendors ship a documented CLI and REST API, so the question is not whether automation exists but what it is scoped to. Translatize binds each integration token to one project and one branch, which means the CI job that pushes keys for feature/checkout-v2 holds a credential that cannot write anywhere else – including main. Combined with admin-and-owner-only merges, that gives you two independent controls over what an automated pipeline can change in production copy.

Real-time collaboration and review state

Every Translatize project member is connected over a WebSocket and is notified when a label is added, edited or merged – no polling, no stale editor. Labels carry a review status of draft, review, approved or rejected, which is deliberately simple: four states, not a configurable workflow engine.

That simplicity cuts both ways. If your process needs multi-step approval chains, per-language reviewer assignment or task queues with due dates, Lokalise's workflow tooling is considerably more developed and you will hit the ceiling in Translatize quickly.

AI translation

Translatize's AI auto-translation fills missing values so a human reviews rather than types from scratch. It is available on Professional and Agency plans only, metered by characters per month – 2M/mo on Professional, 10M/mo on Agency. Free and Starter plans do not include it.

Lokalise offers machine translation and AI-assisted features of its own; treat the two as comparable in kind and evaluate output quality on your own content rather than on marketing claims. Our take on where AI belongs in the pipeline is in AI localization workflow.

Pricing shape

Do not take any number you read in a blog post – including this one – as a current price. Check both vendors' pricing pages.

What is worth comparing is the shape. Lokalise prices on a combination of plan tier, seats and key volume, which scales naturally with a growing localization team but means the bill moves as you add people. Translatize is flat per month: Free $0, Starter $19, Professional $49, Agency $199, with members included per tier (2 / 5 / 10 / 100) rather than billed individually.

On the dimensions covered in this article:

Where Translatize fits

Translatize is a fit when translations are owned by engineers, live next to code, and change per feature branch – and when flat pricing that doesn't move as you add a fifth reviewer suits you better than per-seat billing.

The concrete test takes an afternoon and costs nothing: import your real en.json, create a branch, change the same key on both sides, then merge and see whether the tool lets you name the strategy and resolve the conflict key by key. For a broader field comparison, the best i18n tools of 2026 covers the alternatives.

Wrapping up

Translatize optimises one thing: isolation per branch, deterministic merges, tokens that cannot stray outside their branch, and a CI gate that fails the build when a language falls behind.

If your last localization incident was two branches clobbering each other's strings on the way to production, that is a merge problem, and it is the problem this tool is shaped around. The docs cover the branch model and the API in detail.