Translation management systems, for a team localizing its own software, are the record that replaces the resource files, the XLIFF folder and the spreadsheet: every string key with its source text, its translation in every locale and the status of each, the translation memory the next release is costed from, the handoff generated from the record and read back, and the export the build takes. A TMS translation management system is sold to translation agencies, marketing teams and enterprises as well as to software teams, and most are built for a project manager routing work to vendors; a software team's translation management is about the catalog and the release. This page sets out what a system has to keep for software translation management, how a release runs through it, and what to check before choosing one.
The catalog is the system, everything else is a feature
Every translation management system has, at its core, a table of keys by locales with a status in each cell, and that table is what the team is buying. Vendor routing, machine translation, connectors and dashboards are features on top of it, and a system with all of them and a catalog the developers cannot export is the wrong system. Software translation management is keeping that table true across releases: a key added by a developer appears in it, a key dropped disappears, and a translation that came back from the vendor is recorded against the key it belongs to with the reviewer's status.
The memory is the asset, and it should belong to the team
A TMS keeps a translation memory, the store of every translated segment, and the next release's cost turns on how much of its word count that memory already holds. A memory the vendor holds is leverage the vendor prices; a memory the team keeps and can export in TMX is leverage the team reads before agreeing a quote. The translation memory leverage sheet on this site works that reading from the analysis report's match shares and the vendor's rates, with no account, and Xlifflane Pro keeps the memory against the catalog.
What to check before choosing a system
That the strings can be imported from the formats the developers ship and exported at any time; that the handoff is XLIFF and the read-back is against keys, not line numbers; that the memory exports as TMX; that a status per locale is a first-class field rather than a comment; that plurals and placeholders are validated when a translation comes back; and that the price is one figure for the team rather than a share of every translated word. A system that fails the first or the last will be left within a year, and the leaving is where the catalog gets lost.
Questions people ask about translation management systems
Is a translation management system the same as a CAT tool?
No. A CAT tool is the translator's editor, with the memory and the glossary beside the segment being translated; the TMS is the team's record of the catalog, the statuses and the releases. The translator's CAT tool reads the XLIFF the TMS hands off.
Does a team with one translator need translation management?
It needs the catalog somewhere the developers and the translator both read. The moment a key changes without the translator knowing, or a translation comes back for a key that was dropped, the record is doing the job a spreadsheet was not.
How does a TMS connect to the code?
Through the string files the build reads: resource files, JSON or YAML catalogs, strings or properties files are imported by key and exported back in the same shape. The record is keyed, so the format is a detail of the import and the export rather than of the catalog.