Join early access

Every translation management system looks the same from the front

Every vendor promises memory, AI, review, QA and integrations. The buying decision lives behind that facade: which system owns the source, the workflow, the return path and the bill.

Four houses with different rooflines standing in one row, drawn in white line on a slate ground

The feature list makes every TMS look the same

Put six translation management systems beside one another and the first row of the comparison writes itself. Translation memory. Glossaries. Machine translation. AI. Review. Quality checks. Screenshots. Git integration. API.

Keep going and the table gets wider without getting more useful. Every check mark says a capability exists. None says which system is allowed to change a string, where a conflict is settled, what event sends approved work back, or what happens when that return trip fails.

That is why TMS comparisons so often end with six products looking interchangeable. They are being compared at the facade. The buying decision is in the plumbing.

A useful comparison starts with four ownership questions: where the source lives, where translation becomes authoritative, how approved work returns to production, and which unit makes the bill grow. The answers describe the product more accurately than its feature page does.

Git integration is an ownership decision

“Git integration” sounds like one feature. The vendors’ own documentation describes several different contracts.

Phrase Strings expects a .phrase.yml file in the repository. That file declares which paths are imported and exported, while the service can return translations on a separate branch and open a pull request 1. Crowdin also supports repository configuration, service branches and pull requests, but its guidance goes further: after the initial import, treat Crowdin as the source of truth for translations so that repository uploads do not overwrite unapproved work 2.

POEditor’s GitHub integration is organised around links between project languages and repository files. Import and export are explicit operations, and webhooks can trigger them 3. Lokalise can pull selected base-language files, auto-pull on repository pushes, and create a branch and pull request when translations are exported 4.

All four boxes can honestly say GitHub. They still make different assumptions about authority. A configuration file in the repository, a project database declared authoritative after import, and a set of language-to-file links are not variations in interface. They are different answers to the question “which copy wins?”

Ask the source-of-truth question separately for source strings and translations. The repository may own one while the TMS owns the other. Saying “Git is the source of truth” without naming the artifact hides that split.

The return path is harder than the import

Most demos spend their time on ingestion. Connect a repository, upload a file, watch a string appear. That is the easy half.

The return path decides whether localization belongs to the release process or runs beside it. Does approval create a pull request, update a service branch, expose a downloadable bundle, call a webhook, or wait for somebody to press Export? Does it preserve the file layout the build expects? Does it overwrite target-side edits? Can it return only approved locales? Can the generated commit pass the repository rules used for every other code change?

These details are not implementation trivia. Phrase documents that its sync needs repository read and write access, a valid configuration file, and a branch that the integration can use; it also notes that some authentication choices fail against repositories requiring signed commits 1. Crowdin uses service branches so translations can be verified before merge and warns that uploading translations back from the repository can override work already in progress 2.

A connector logo proves that two systems can exchange data. It does not prove that the exchange respects your branch protection, release cadence, ownership rules or conflict policy. Those are the things the pilot has to exercise.

A screenshot feature is not the same as current context

Screenshot support has the same problem. A screenshot can be a loose project attachment, a picture linked to a key, an interactive preview, or a maintained capture of the screen on which a string actually appears.

Phrase lets a team attach keys to regions in a screenshot and shows those screenshots in the translation editor 5. Lokalise likewise links screenshots to keys and highlights the linked text for the translator 6. The capability is real. So is the maintenance job behind it.

A screenshot becomes stale when the screen changes, and a key can appear in more than one place with different meanings. The feature matters only if the workflow captures new screens, maps the right keys and tells somebody when the mapping is no longer trustworthy. Context is not present because the product has a Screenshots tab. It is present because the current string reaches the reviewer with current evidence of where it is used.

The meter is part of the architecture

Pricing is another architecture diagram disguised as a table. A meter tells you what the vendor has decided is scarce.

Phrase distinguishes consumable capacities such as processed words, machine-translation units and AI units from stored capacities such as managed words and seats. Exhausting different capacities restricts different parts of the workflow 7. That is not merely a complicated way to present a subscription. It means the cost boundary runs through several operational events.

MeterBill grows withIncentive
Stored strings or wordsCatalog size and target coverageRemove duplicates and dormant content
Processed wordsSource changes sent to target localesReduce churn and preserve exact reuse
Privileged seatsPeople allowed to operate the workflowConcentrate control in fewer accounts
MT or AI unitsContent sent through provider featuresRoute selectively and avoid repeat calls
Four meters can price the same catalog four different ways. The cheapest plan at rest may be the most expensive one after the product starts changing.

We have written about why processed-word billing follows what you touch rather than what you keep. The wider procurement lesson is that no monthly price is comparable until it has been applied to the same repository, locale count, change rate, user roles and automation volume. The unit is part of the product.

Some products put a different system in the middle

Some products are not even trying to put the same artifact in the middle. Smartling’s Global Delivery Network can sit between a website and its visitors, replacing content in transit through proxy and client-side technology. Its documentation explicitly presents that route as a way to localize without hosting translations in the source system 8.

Compare that with a repository flow whose final artifact is a reviewed resource file in a pull request. One changes what the application ships. The other can change what the visitor receives. Both can translate a website, but they place the operating boundary in different infrastructure.

This is why “too much TMS” is often the wrong diagnosis. A platform built around vendor management, content connectors, web delivery and enterprise controls may be excessive for a small app team. It may be exactly right for a localization programme spanning a CMS, support centre, product interface and outside language providers. The mistake is not buying the larger system. It is buying an operating model you do not have.

Pilot the handoff, not the editor

The shortest useful TMS evaluation is not a tour. It is one complete change through the proposed production path.

ChangeEvidenceFailure to provoke
Edit one source messageOnly the intended source change enters the projectRename its key after the first sync
Translate into two localesContext, terminology and placeholders reach both candidatesBreak a placeholder in one locale
Approve one and reject oneRelease state differs by locale without ambiguityAttempt export with one locale blocked
Return approved workA reviewable artifact reaches the real repository or runtimeCreate a target-side conflict before return
Run the buildThe application consumes the returned artifact unchangedApply normal branch and CI protections
A good pilot includes a rejection, a conflict and a structural error. A happy-path import demonstrates the part every product has already polished for the demo.

Record who resolves each failure and in which system. Then price the run using the vendor’s actual meters. At the end you will know more than whether the editor felt pleasant. You will know which copy was authoritative, which events were automatic, which handoffs needed a person, and which actions consumed capacity.

Every TMS still looks similar from the street. That is fine. You do not live in the facade. You live with the ownership rules, the return path and the meter behind it.

References

  1. 1.Phrase GitHub (Strings) Phrase Support
  2. 2.Crowdin GitHub Integration Crowdin Docs
  3. 3.POEditor How to translate a language file from a GitHub project POEditor Help
  4. 4.Lokalise, 2026 GitHub Lokalise Help Center, 7 July 2026
  5. 5.Phrase Screenshot Management (Strings) Phrase Support
  6. 6.Lokalise, 2026 Screenshots Lokalise Help Center, 19 June 2026
  7. 7.Phrase Localization Platform Pricing Phrase Support
  8. 8.Smartling Introduction to the GDN Smartling Help Center