A TBX import is only successful if the structure survives it. ISO 30042 term entries are concept-oriented and carry part of speech, usage context, definition, administrative status — preferred, admitted, deprecated — and provenance. A two-column CSV carries none of that, and a platform that flattens TBX into source and target pairs on import has silently discarded the fields that make terminology enforceable rather than advisory. The most damaging single loss is status: when a deprecated term imports as an ordinary synonym, the term base now actively authorises the wording it was built to prohibit.
This checklist covers what to inspect before importing, the encoding and duplicate-handling decisions that determine whether entries ever match, and the four verification steps that prove the import took effect in the engine rather than only in the settings screen.
What a Concept-Oriented Entry Carries
TBX models a concept first and languages second. One entry holds the idea; each language section holds the terms that express it, with per-term metadata. That shape has practical consequences a spreadsheet cannot reproduce.
A single concept can hold six languages at once, so a decision recorded against the concept — a definition, a subject field, a client attribution — applies to all of them. In a CSV, six languages means six unrelated files that drift apart the moment one is edited.
Each term carries its own status, so preferred, admitted and deprecated variants coexist inside one entry instead of competing as separate rows. Each carries a part of speech, which is what distinguishes the noun charge from the verb. Each can carry a context sentence showing correct use, which is what a reviewer needs when deciding whether a flagged override was justified.
Provenance — who approved this, when, under what authority — travels with the term rather than living in a filename.
The Fields That Disappear Without an Error Message
Bad imports rarely fail loudly. They succeed, report a plausible entry count, and quietly drop everything the importer does not model.
Status. Deprecated and admitted terms become plain alternatives. Nothing warns you.
Part of speech. Homographs collapse into one entry, and the engine starts enforcing a noun rendering inside a verb phrase.
Context and definition. These are the fields a human needs to adjudicate a conflict. Losing them turns every flagged term into a research task.
Subject field and domain. Without it, a banking sense and an insurance sense of the same term become a duplicate collision rather than two valid entries.
Cross-references. Links between related concepts vanish, and so does the ability to see that two entries are meant to be consistent.
Match and case flags. Case sensitivity and whole-token settings often reset to a default that fires everywhere.
Ask the vendor which of these six the importer stores. The answer says more about real glossary enforcement than any feature page.
Encoding, Normalisation and Invisible Characters
Terminology fails silently at the byte level more often than at the linguistic level.
Export as UTF-8 and check for a byte-order mark. A BOM in front of the XML declaration makes strict parsers reject the file, and lenient ones absorb it into the first entry's identifier. Files that have round-tripped through a Windows-1252 spreadsheet arrive with mojibake — é rendered as é — which is visible if you look and invisible if you import 4,000 rows without looking.
Unicode normalisation is the subtler trap. A Vietnamese, Korean or accented French term stored decomposed (NFD) will not match the same term composed (NFC) in the source document, even though both render identically on screen. Normalise the term base and the matching path to the same form, and confirm which form the platform uses.
Then strip the invisibles: non-breaking spaces inside terms, trailing whitespace, smart quotes where the document uses straight ones, soft hyphens inherited from a PDF. Each produces an entry that looks correct and never fires.
Language Tags Have to Match the Job
Term bases are indexed by language tag, and a mismatch means the entry is present, valid, and completely inert.
The classic failure is Chinese. Terms filed under zh will not necessarily fire on a job configured as zh-Hant, and Simplified entries applied to a Traditional deliverable are worse than no entries at all. Portuguese splits the same way between pt-PT and pt-BR, and so does Serbian across scripts.
Regional variants matter in regulated content. Austrian and Swiss German legal and accounting vocabulary diverges from German German on exactly the terms a term base exists to control — an entry under de may be wrong for a de-AT filing.
Check three things before importing: that every tag is well-formed under BCP 47, that the tags in the file match the locales configured in the project, and that the platform's fallback behaviour is documented. Locale conventions themselves — date order, decimal separators, sorting — come from CLDR rather than from your term base, and confusing the two produces entries that try to legislate number formatting.
Duplicate and Overlapping Entries
Duplicates are not all errors, so an importer that deduplicates on source string alone will destroy legitimate entries. Two entries with the same source term and different targets are correct when they carry different subject fields, different parts of speech, or different statuses.
Decide the policy before you import, because every platform has a default and few announce it: reject the file, first entry wins, last entry wins, merge into one concept, or flag for review. Merge is usually right for a curated base and dangerous for a file assembled from three teams' spreadsheets.
Then handle overlap, which is different from duplication. Material Adverse Effect and Material Adverse Change share a prefix; Board is a substring of Board of Directors. The requirement is deterministic longest-match precedence, not import order. Add case variants and trailing punctuation to the same clean-up pass — Company, company and Company, are three entries in most importers and one term in reality.
Matching Behaviour Decides Whether Anything Fires
An import can be technically perfect and still change nothing, because the entry never matches the text in the document.
Surface matching fires only on the exact string. An entry for Affiliate will not fire on Affiliates, and an entry for undertake will not fire on undertaking. Lemma-aware matching handles both but requires morphological analysis of the source language, which not every platform runs on every language.
The reverse problem appears in the target: an entry gives one target form, but the sentence requires a case, gender or number the entry does not contain. That is where terminology collides with grammar, and how a platform handles it is the single most consequential design choice in the whole feature — covered in detail in the guide to glossary conflict resolution.
Ask whether matching is surface, stem or lemma; whether it runs before or after segmentation; and whether entries can be scoped so a term only fires in specified sections or document types. These questions separate working glossary support from a settings field.
Pre-Import Hygiene, in Order
Run these in sequence, on a copy.
Validate the XML against the TBX-Basic dialect. A file that does not validate will import partially, and the missing part is rarely the part you would notice.
Reconcile the entry count you expect with the count in the file, before the importer gives you its own number.
Remove empty targets. An entry with a blank target either does nothing or blanks the term, and both happen in the wild.
Strip markup from term fields. Terms copied out of a CAT tool sometimes carry inline tags, which then match nothing.
Check for terms that are also common words and set case and whole-token flags explicitly rather than accepting defaults.
Freeze a known-good copy of the file. You will need it for the round-trip test below, and for the next vendor.
Teams running this at volume across many language pairs describe the same operational pain in this r/machinetranslation thread on large-scale multilingual translation.
Verifying the Import Took Effect
Four checks, in increasing order of confidence.
Count reconciliation. Compare entries in, entries stored, entries rejected. If the platform reports only a success message, that is itself a finding.
Field spot-check. Open a term you know is deprecated and confirm the status survived. Open a homograph pair and confirm both entries kept their parts of speech.
Round-trip export and diff. Export the term base back to TBX and diff it against the frozen copy. Everything the importer discarded shows up as a deletion. This is the fastest real test of a terminology implementation.
Canary document. Translate a short document seeded with a preferred term, a deprecated term, a homograph in both senses, and a term needing inflection. Then read the enforcement report — which terms fired, which were overridden, and where. Bluente exposes term base enforcement through the same document translation API that returns the formatted output, so this check can run on every batch rather than once during procurement.
If you are also moving in-progress work, confirm XLIFF 2.1 support alongside TBX — term bases and segment-level markup travel together.
Sources and Further Reading
XLIFF 2.1 — OASIS bitext interchange, including inline markup
Unicode Collation Algorithm (UTS #10) — language-aware string comparison for duplicate detection
r/machinetranslation on large-scale multilingual translation — teams weighing terminology infrastructure against volume and budget
Related Reading
Last reviewed 24 August 2026 by the Bluente document engineering team, who build and test the pipeline described here. We update these guides when the underlying standards, regulations or file formats change.
Import the term base, then prove it survived the trip. Try BluTranslate free.