TBX Export & Import – Exchanging Terminology Between Tools
TBX (ISO 30042) is the standard format for exchanging terminology. In practice, language codes, status mapping and field mapping determine whether imported data is actually usable.
The TBX series – from overview to practice
- Overview
- Understanding the structure
- What information TBX can carry
- Export & import in practice (this page)
TBX rarely fails because of the format itself. Most problems arise from small but critical details: mismatched language codes, unclear term status, or missing field mappings.
This page focuses on the practical side of TBX: how terminology is exchanged between systems, what typically goes wrong, and how to avoid unpleasant surprises.
Typical exchange scenarios
- Termbase → CAT tool: translators receive validated terminology.
- CAT tool → termbase: new term proposals are returned for review.
- Termbase → authoring system: authors write consistently.
- Partner → company: terminology is imported and harmonised.
Why “TBX in” does not automatically mean “TBX out”
Although TBX is standardised, tools support different subsets of the standard. As a result:
- one tool imports definitions, another ignores them
- one tool supports three status values, another supports five
- some tools flatten concept structures into term lists
This is normal. TBX is a common language – not a guarantee of identical behaviour.
Preparing a TBX export
1. Decide what really needs to be transferred
Not every exchange requires full terminological depth. Define upfront whether you need only preferred terms, or also definitions, context, sources and metadata.
2. Align language codes
A classic issue:
the export uses en,
the target system expects en-US or en-GB.
TBX uses xml:lang,
but tools are often strict about accepted values.
3. Map term status explicitly
Status values are more critical than they look. If one system uses preferred / admitted / deprecated and another uses preferred / alternative / rejected, you must define a clear mapping.
A proven minimal set for stable exchange
For most workflows, the following minimal set works reliably across tools:
- Concept ID (termEntry @id)
- Language (
xml:lang) - Term
- Status
- Definition (if supported)
Common pitfalls during import
Duplicate entries
Without stable IDs, systems may create new entries on every import. Ensure that the target system can update existing concepts instead of always creating new ones.
Flattened concepts
Some tools are not fully concept-oriented. They may merge different concepts if the same term appears more than once. This can be dangerous in technical domains.
Silent data loss
Information may be present in the TBX file but disappear on import because the target system has no corresponding field. Always test with a representative dataset.
A 7-step TBX transfer checklist
- Clarify the goal: who needs the data, and for what purpose?
- Define the minimal set: which fields must survive the transfer?
- Standardise language codes: one format, everywhere.
- Define status mapping: document it.
- Create a test export: small but realistic.
- Review the import: check structure, status and completeness.
- Document the rules: for future exchanges.
Conclusion
TBX makes terminology exchange predictable – as long as expectations are aligned. Clear language codes, explicit status mapping and tested field mappings turn TBX from a risky experiment into a reliable workflow.