Translatize vs Crowdin

Crowdin and Translatize both manage translations for software teams, but they were built around different centres of gravity: Crowdin around community and open-source localization at scale, Translatize around release-aligned branching for a small-to-medium product team. Comparing them on a feature checklist makes the gap look narrower than it actually is.

This is written by the Translatize team, and it compares the two on a specific set of dimensions: the developer workflow on both sides, what happens when two feature branches touch the same keys, review state, software file formats, and how the two pricing models differ in shape rather than in headline number. Both products do more than this list – for a vendor-neutral read of the wider category, see Lokalise vs Crowdin vs Phrase.

The short version

Both tools store keys, hold a translation per language, expose a CLI and an API, and have a concept of branches. The dimensions worth comparing are how central branching is, what a merge is allowed to do when the same key changed on both sides, and who is permitted to write to main.

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

Where each one comes from

Crowdin has been around since roughly 2009 and grew up alongside open-source and community translation. It has one of the largest integration catalogues in the category, an app marketplace, and support for a very wide list of file types.

Translatize is younger and narrower on purpose. Its organising idea is that translations should branch the way code branches: create a branch per feature, translate in isolation, then merge back to main under permission gates. Everything else – the format list, the CLI, the API, the webhooks – hangs off that model.

Developer workflow

Crowdin is configuration-first. A crowdin.yml at the repo root maps sources to translations once, and the CLI stays short afterwards:

project_id_env: CROWDIN_PROJECT_ID
api_token_env: CROWDIN_PERSONAL_TOKEN
base_path: '.'
preserve_hierarchy: true
files:
  - source: /locales/en/*.json
    translation: /locales/%two_letters_code%/%original_file_name%

crowdin upload sources
crowdin download --language de

Crowdin also offers a GitHub integration that opens translation pull requests for you, which is the path most open-source projects take because it needs no CI wiring at all.

Translatize is token-first. An integration token is prefixed mcni_ and is bound to exactly one project and one branch, so the scope lives in the credential rather than only in a config file. Setup is one init command, which writes a translatize.config.json recording the project id, the on-disk file pattern and whether your JSON is nested or flat:

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

The token is never written to that file – it is read from TRANSLATIZE_API_TOKEN or a --token flag at run time. After that there are three commands:

export TRANSLATIZE_API_TOKEN=mcni_xxx

npx translatize pull   --branch feature-checkout
npx translatize push   --branch feature-checkout
npx translatize status --branch feature-checkout --fail-on-missing

pull writes one file per project language, push uploads only new and changed keys and never deletes remote ones, and status compares the two sides and is the command you put in CI as a gate. The same operations are available through the @translatize/core SDK if you would rather script them, and there is an MCP server (@translatize/mcp) that exposes them to an AI coding agent – useful if you want a model to add missing keys as part of a normal edit loop. GitHub Action and GitLab CI templates wrap the CLI for the usual pipeline case, and webhooks fire on label and branch events if you want to react to changes elsewhere.

Both approaches work, and they make different trade-offs. Crowdin's puts the whole mapping in one committed file. Translatize's puts the boundary in the credential: a token is issued against one project and one branch, so a leaked CI token cannot reach a branch it was not issued for – the blast radius of a compromised pipeline secret is one feature branch rather than the whole project.

Branching, which is the real difference

Crowdin supports version branches, and for the common case – a feature branch collects new strings, translators work on them, the branch is merged – that is enough. What Crowdin does not present is branching as a first-class merge model with named, selectable semantics.

Translatize does. A merge is an explicit request that names a target branch and a strategy:

{
  "target": "main",
  "strategy": "keep-newer"
}

The four strategies are:

• overwrite – the default, and non-destructive. A union of both branches: keys and languages that exist only in the target are preserved, source-only additions are merged in, and on a genuine per-language conflict the source value wins.
• replace – destructive. The target branch becomes a copy of the source. Useful after a deliberate rewrite, dangerous otherwise.
• keep-newer – the more recently modified label wins. Timestamps are per label rather than per language, and the source only wins when it is strictly newer, so an equally-old source never silently overwrites the target.
• manual – you fetch the conflicting keys first and resolve each one before the merge commits.

The conflict payload is a flat list, one row per conflicting language, which makes it easy to render in a UI or script in CI:

{
  "source": "feature-checkout",
  "target": "main",
  "conflicts": [
    {
      "key": "checkout.button.submit",
      "lang": "de",
      "sourceValue": "Jetzt kaufen",
      "targetValue": "Kaufen"
    }
  ],
  "hasConflicts": true,
  "conflictCount": 1
}

Each row is then resolved as source, target, or a custom value, and the resolutions are sent back with the merge.

Merges are permission-gated by project role. The roles are owner, admin, developer and translator. Developer and above can create branches, only the creator or an admin can delete one, and only an admin or owner can merge into main. That last rule is the point of the whole model: a translator can work freely on a feature branch with no possibility of changing what production is serving.

If your release process is "cut a branch, ship it, merge it", this maps onto it directly. If your process is "strings land continuously in one pool and get translated over time" – which describes most open-source projects – you will not feel the benefit, and Crowdin's simpler version branches are less machinery for the same outcome.

Review state

Both tools model review as an explicit stage rather than leaving it implicit.

In Translatize, every label carries a review status of draft, review, approved or rejected, which covers a two-stage human review, and every project member is notified over a WebSocket connection the moment a label is added, edited or merged – so two people working the same screen see each other's changes without refreshing. AI auto-translation fills missing values for a human to review afterwards, rather than being treated as a finished translation.

The part that is specific to Translatize is how review interacts with branching: a translator can be given a feature branch to work in with no path to modifying production strings, because merging into main is restricted to admins and owners. Review state and merge permission are the same system rather than two.

Software file formats

Nine formats covers app localization: web, mobile, desktop and the gettext ecosystem. Six of them are single-language files; JSON, YAML and CSV carry every language in one file, which matters when you are diffing a translation change in a pull request. Note the split of responsibilities on the Translatize side: the CLI syncs JSON files on disk, while the full nine-format import and export runs through the app and the API. See how to translate YAML files and translating Flutter ARB files for format-level detail.

Pricing shape

Crowdin publishes per-tier pricing with limits on strings, projects and seats, plus a separately-sold enterprise product for SSO and workspace isolation, and a free program for qualifying open-source projects. Numbers change, so check crowdin.com rather than trusting any figure quoted in a blog post – including this one.

Translatize is four flat tiers:

AI auto-translation is available on Professional and Agency only, metered by characters per month. Signup is self-serve, and the free plan does not expire and does not ask for a card.

The structural difference is what to compare. Crowdin's model scales with strings and seats and has an enterprise step above it; Translatize flattens key, project and branch limits at $49 and then charges for people and AI volume. Which is cheaper depends entirely on your shape – a two-person team with 80,000 keys and a fifty-person team with 5,000 keys land in very different places on the two curves, so price both against your real numbers rather than against a tier name.

Where Translatize fits

Translatize is a fit when your translations should follow your release branches, you want merge behaviour you can name and permissions that stop a translator touching main, you have a small team that would rather configure four things than forty, and your content is app strings in the nine supported formats. See the docs for the API and the branch model, or Translatize vs Lokalise for the other common comparison.

Wrapping up

Translatize is a narrow tool with one strong opinion – branches – and it is worth evaluating on whether that opinion matches how you ship.

The practical test takes an afternoon and costs nothing on either side: import your real en.json, create a feature branch, have someone translate ten keys, then merge and see what the tool does with a key that changed on both sides. Whichever one makes that sequence feel unremarkable is the one to keep.