TMX and TBX explained: portable formats for translation memory and terminology

A localization project's most valuable output is not any single translated file — it is the accumulated record of every sentence that has already been translated and every term the team has agreed on. Two open, vendor-neutral XML formats exist specifically to carry that record between tools without losing it: TMX for translation memory, and TBX for terminology. Neither is a UI string format like the ones used to ship an app; both are interchange formats, built to move linguistic assets in and out of whatever tool happens to be in use.

TMX: what a translation memory actually stores

A translation memory is not a dictionary. It is a growing database of source-and-target sentence pairs pulled from real translation work — every sentence a translator has confirmed, paired with its translation, becomes an entry the next translator can be shown as a suggestion or an exact match. TMX (Translation Memory eXchange) is the format that lets that database move between tools instead of being locked inside one vendor's memory store.

The core structural unit is the translation unit, and inside it, one translation-unit-variant per language, each holding a segment — the actual sentence or phrase text for that language.

<tu>
  <tuv xml:lang="en">
    <seg>Are you sure you want to log out?</seg>
  </tuv>
  <tuv xml:lang="de">
    <seg>Möchten Sie sich wirklich abmelden?</seg>
  </tuv>
</tu>

A translation unit can carry metadata alongside the segments — when it was created, which tool or translator produced it, which project it came from — which is what lets a translation tool later show a translator not just a matching sentence but the context of where that match came from and how much to trust it.

The practical value of TMX is portability: a translation memory built up over years inside one tool is not stranded there. Exporting it as TMX and importing it into a different tool preserves the sentence pairs, so a team that changes tooling, brings in an outside vendor, or simply wants a backup of its own accumulated work is not rebuilding that memory from zero.

TBX: what a terminology database actually stores

Terminology is a different kind of asset from translation memory, and it solves a different problem. A translation memory records what has been translated before; a terminology database records what a specific term should always be translated as, independent of the sentence it appears in — a product name that must never be translated, a technical term with one approved rendering, a word the style guide explicitly forbids using a certain way. TBX (TermBase eXchange) is the portable format for that database, standardized through the same LISA/OASIS-adjacent lineage as TMX.

TBX structures a term entry around a concept rather than a sentence: one concept, one entry, with a language-specific term section per language and room for the kind of metadata a glossary spreadsheet usually loses — part of speech, a usage note, a status like approved or deprecated, and a definition.

<termEntry id="c001">
  <descrip type="definition">The in-game currency spent on cosmetic items</descrip>
  <langSet xml:lang="en">
    <tig><term>Gem</term><termNote type="partOfSpeech">noun</termNote></tig>
  </langSet>
  <langSet xml:lang="de">
    <tig><term>Edelstein</term><termNote type="status">approved</termNote></tig>
  </langSet>
</termEntry>

The unit and segment structures, conceptually

Both formats are organized around the same idea at different granularity. TMX's unit is the translation unit — one source sentence and its translations across languages, with the segment being the literal text of one language's version. TBX's unit is the concept — one thing in the world that needs a name — and the term entry holds every language's approved name for that concept, not a sentence containing it.

That distinction is the whole reason two formats exist instead of one. A translation memory match is inherently approximate: two sentences can be similar enough to be a useful suggestion without being identical, and a translator decides case by case whether to accept, edit, or reject the match. A terminology entry is meant to be closer to a rule: once a term is marked approved, a QA check can flag any translation that uses a different rendering of that same source term, because there usually is no acceptable variation the way there is for ordinary sentence translation.

Why portable formats matter for owning your linguistic assets

The reason both formats exist as open standards rather than each tool inventing its own is straightforward: a translation memory or terminology database is a long-lived asset that usually outlives the tool that created it. A game studio's approved terminology and its accumulated translation memory represent years of decisions and paid translation work; if that record only exists inside one tool's proprietary storage, switching tools — or working with a translator who uses a different one — means starting over.

TMX and TBX exist specifically so that does not happen. Because they are XML-based and openly specified rather than tied to any single vendor, essentially any serious translation tool can import and export both, which makes the underlying linguistic asset the thing a team actually owns, independent of which tool it happens to be using this year.

How this differs from a glossary kept in a spreadsheet

A spreadsheet glossary — source term, target term, one row per language pair — looks like it does the same job as TBX, and for a small, single-language-pair project it can be enough. But it breaks down in ways TBX is specifically structured to avoid:

• A spreadsheet has no standard way to attach a definition, usage note, or approval status to a term — those end up as free-text comments a tool cannot read
• A spreadsheet with one column per language does not scale cleanly past a handful of languages, and adding a language means restructuring every row
• Nothing in a spreadsheet format enforces that a term entry represents one concept — the same English word used for two different meanings often ends up as two indistinguishable rows
• A spreadsheet is not importable by translation tooling in a structured way, so terminology checks have to be built by hand against it rather than run automatically

A spreadsheet is not wrong for a small project — it is simply a format nothing else was built to read. TBX exists for the point where terminology needs to be enforced by tooling, shared with outside translators, or trusted to outlive the spreadsheet's original author.