Guide

Do you actually need a TMS?

2026-06-10 · 4 min read

A translation management system is workflow software: assignment queues, translation memory, glossaries, reviewer roles, vendor handoff. If you employ or contract translators who need a place to work, that is what a TMS is for, and the good ones are genuinely good at it.

Most engineering teams evaluating a TMS do not have that problem. They have a folder of JSON files, translations that arrive from an agency, a teammate, or a model, and a recurring incident: something shipped broken in a language nobody on the team reads. That is not a workflow problem. It is a quality problem, and a TMS is a heavy way to not quite solve it.

The honest decision table

What a TMS does not gate

A TMS knows the status of strings inside the TMS. The hotfix string a developer committed directly, the file an agency emailed back, the locale folder a model regenerated: none of it passes through the workflow, so none of it gets checked. The deploy does not ask the TMS for permission. Unless something in CI looks at what actually ships, the gap between "managed" and "shipped" is exactly where the embarrassing bugs live.

The third option

Between "buy a TMS" and "a teammate wrote a key-diff script" there is a third shape: keep strings in git, let anything produce them, and run an independent scan in CI that scores every language, catches the 13 mechanical failure classes from missing keys to stale strings, and fails the build on regression. That is Polylens. It replaces nothing in your pipeline and refuses to let it rot.

It is also not either-or. Teams with a TMS put the gate after export, because the TMS checks what translators saved and the gate checks what the app ships. If you are choosing today: start with the gate, free for one project, and buy workflow software the day you actually hire translators.

Get a health score for your locale files in under a minute. Free for one project.

More from the blog: all posts