Translatize vs Phrase
Translatize and Phrase compared on branching and merge behaviour, software file formats, developer automation, review state and pricing shape.
Updated October 20, 2026
Phrase and Translatize both call themselves translation management platforms, but they were built for different problems and it shows within about ten minutes of using either one. Phrase is an enterprise localization suite with a professional CAT-tool lineage; Translatize is an engineering-led tool built around git-style branching of your translation keys.
This is written by the Translatize team, and it compares the two on a specific set of dimensions: how a feature branch flows through each, software format coverage, developer automation, review state, and the shape of the pricing. Both products do more than this list – for a vendor-neutral read of the wider category, see Lokalise vs Crowdin vs Phrase.
What Phrase is
Phrase started life as PhraseApp, a developer-focused tool for software strings. It later came together with Memsource, the computer-aided translation company behind what is now Phrase TMS, and the result is a suite with two distinct halves:
- Phrase Strings – the PhraseApp lineage. Key/value software localization, a
.phrase.ymlconfig, a CLI, branches, and integrations with the usual repos and design tools. - Phrase TMS – the Memsource lineage. A computer-aided translation environment: segmentation, translation memory, term bases, analysis reports, and vendor/job management.
The relevant half for this comparison is Phrase Strings, because that is where the two products overlap: keys, languages, branches, a CLI and an API. Phrase TMS is a different production model aimed at professional linguist supply chains, and it is outside the scope of what is compared here.
What Translatize is
Translatize is narrower on purpose. Its core idea is that translation keys should behave like code:
- Branches. Create a branch per feature, add and translate keys in isolation, merge back to
main. - Merge strategies.
overwrite(non-destructive union, source wins on conflict),replace(destructive – target becomes a copy of source),keep-newer, andmanualfor case-by-case conflict resolution. - Permission-guarded merges. Roles are owner, admin, developer and translator. Developer and above can create branches; only the creator or an admin can delete one; only admin or owner can merge to
main. - Real-time collaboration over WebSocket – every project member is notified when a label is added, edited or merged.
- Review statuses on each label: draft, review, approved, rejected.
- Nine import/export formats, a REST API, webhooks for label and branch events, and a devtools set:
@translatize/cli, the@translatize/coreSDK, an MCP server, plus GitHub Action and GitLab CI templates. - AI auto-translation that fills missing values for a human to review, available on the Professional and Agency plans and metered by characters per month.
Side by side
On the dimensions covered in this article:
| Translatize | Phrase | |
|---|---|---|
| Centre of gravity | Engineering-led product teams | Enterprise localization programs |
| Product shape | One product | Phrase Strings + Phrase TMS |
| Feature-branch model | Branching with four explicit merge strategies | Branches in Strings; job/version workflows in TMS |
| Merge conflict handling | Named strategies incl. manual key-by-key resolution | Platform-managed |
| Merge permissions | Only admin/owner may merge to main | Role-based project permissions |
| API tokens | Bound to one project and branch | Project-scoped tokens |
| Software formats | Nine: JSON, YAML, CSV, XLIFF 1.2, PO, ARB, RESX, Android XML, iOS .strings | Broad software format coverage |
| Real-time collaboration | WebSocket notifications on label and merge events | Collaborative editor |
| Automation | REST API, mcni_ integration tokens, CLI, SDK, MCP server, GitHub Action, GitLab CI | CLI, REST API, GitHub Action, many integrations |
| Pricing shape | Flat published plans with optional extra seats, self-serve | Modular per product, seats plus volume, frequently annual and quoted |
Pricing above describes shape only. Phrase's published and quoted pricing changes; check their pricing page rather than trusting any number in a blog post.
How a feature branch flows through each
Say a checkout redesign adds forty keys and renames six, while another team is mid-flight on a settings rewrite.
In Phrase Strings, you push the branch and pull it back:
phrase push --branch "$GIT_BRANCH"
phrase pull --branch "$GIT_BRANCH"
Translation happens in the branch, then you merge it. If the work goes to an LSP, it more likely leaves Strings entirely and becomes a TMS job: analysed against the translation memory, quoted, assigned, translated, reviewed, delivered. That detour is overhead if your strings are three-word button labels – and exactly right if they are legally reviewed onboarding copy.
In Translatize, the branch is the unit of work end to end. Push source keys from CI with a project- and branch-bound mcni_ token:
npx @translatize/cli push \
--file locales/en.json \
--format json \
--branch "$GIT_BRANCH"
npx @translatize/cli pull \
--format json \
--branch "$GIT_BRANCH" \
--out locales/
When the feature ships, whoever holds admin or owner merges to main with an explicit strategy – overwrite for the normal additive case, keep-newer when both branches edited the same keys and recency is the right tiebreak, manual when someone has to actually look. The guard rail is that a developer cannot quietly merge half-translated keys into main; the permission check is enforced server-side.
Neither tool makes conflicts free. Two branches setting checkout.submit to different strings still needs a human. Short branches merged often beats any merge algorithm on either platform.
Formats and round trips
Translatize imports and exports nine formats. JSON (nested or flat), YAML and CSV carry every language in one file; XLIFF 1.2 is bilingual, pairing each translation with its source; PO, ARB, RESX, Android XML and iOS .strings are single-language per file.
{
"checkout": {
"submit": "Place order",
"empty": "Your cart is empty"
}
}
That list covers the common software stacks. Phrase covers those plus a long tail, and – through TMS – document formats that a strings tool structurally cannot handle. If part of your localization budget goes to PDFs, InDesign files or subtitles, that gap is decisive.
Whichever you pick, run the same test before committing: push one real locale file from your repo, change two strings, pull it back and diff. Plural forms, ICU messages and comment preservation are where round trips quietly break, and a clean diff tells you more than any feature matrix. If you want a worked example of that loop, translating JSON files with AI walks through it.
AI and machine translation
Both platforms offer AI translation and both meter it separately from the base subscription.
Translatize's AI auto-translation fills missing values across the target languages of a project so a human reviews rather than types, gated to the Professional and Agency plans and metered by characters per month. The design intent is a first pass inside a human-review workflow – output lands as a value a reviewer moves through draft → review → approved, not as a finished translation. That pattern is described in full in the AI localization workflow.
Pricing shape, not numbers
Phrase licenses Strings and TMS separately or together, typically per seat plus a volume component, often annually, with quotes at the upper end and an enterprise buying motion around it. That is a normal enterprise model, and it comes with what enterprises want in return: negotiated terms, support commitments, compliance paperwork.
Translatize publishes flat plans and sells them self-serve: Free at $0 (1000 source keys, 1 project, 2 branches, 2 members, no AI), Starter at $19/mo (10k keys, 5 projects, 5 branches, 5 members, no AI), Professional at $49/mo (unlimited keys, projects and branches, 10 members, AI on with 2M characters/month), and Agency at $199/mo (up to 100 members, 10M AI characters/month). Signup needs no credit card and the free plan does not expire.
The one budgeting question worth asking either vendor: which people consume a paid seat. Reviewers, CI-only developer accounts and external freelancers can double an effective cost if they each count.
Where Translatize fits
Translatize is a fit when you are a smaller engineering-led team, your content is application strings, and your real pain is that translations do not follow your branches: branch-per-feature with explicit merge strategies, permission-guarded merges to main, nine formats, tokens bound to a single branch for CI, and a flat price you can read off a page.
To see how it compares to the mid-market alternatives, Translatize vs Lokalise and the best i18n tools of 2026 cover that ground, and the docs show the branching model in detail.
Wrapping up
Translatize is the answer when translation is part of your development workflow and the hard part is keeping keys in sync with branches.
The fastest way to decide is to describe your next quarter honestly. If it involves six feature branches and a CI job that keeps forgetting to pull new keys, that is the problem this tool is shaped around – import your real en.json, branch, change the same key on both sides, and see what the merge does.
