top of page
Search

TBX vs CSV: Which Glossary Format for Regulated Content?

11 minutes ago
9 min read

Localization specialists compare glossary file formats

Use TBX (TermBase eXchange) when a term base must move between tools, vendors or audits without losing structure. Use CSV only for small, flat glossaries inside one controlled workflow. TBX is an XML-based international standard, ISO 30042:2019. CSV has no formal standard for terminology storage.



Table of Contents

 

 

What are TBX and CSV, and what does each cover?

 

TBX stands for TermBase eXchange. It is an international, XML-based standard for exchanging structured terminological data between software applications and systems, published as ISO 30042:2019. The format is designed as a framework for interchange of terminological data between users, applications and systems.

 

CSV stands for comma-separated values. It is a plain text table. Each row is a record and each column is a field. The columns and values can be arbitrary, and the format has no formal standard for terminology. Any meaning of a column exists only by agreement between the people who create and read the file.


TBX hierarchy compared with flat CSV rows

The scope of this comparison is a US-based localization team that manages glossaries and term bases for regulated content. Typical document types are clinical and device documentation, contracts, financial disclosures and technical manuals. The data category is terminology: terms, definitions, usage notes, status and context. The comparison does not cover personal data or translation memory ™ exchange formats.

 

How do TBX and CSV differ in structure?

 

TBX is concept-oriented. One concept entry can contain several language sections. Each language section can contain several terms. Terms inside one entry are assumed to be synonyms unless otherwise noted. The structure keeps a concept, its definition and its translations together.

 

TBX is also modular. The standard supports different types of terminological data and data categories. Different terminology markup languages can use subsets or supersets of those data categories. TBX-Basic is one such subset. It is a more manageable way to exchange translation-oriented terminology while keeping structural integrity.

 

CSV is row-oriented. A typical glossary has one row per source and target pair, with columns such as source term, target term, definition and status. A concept with synonyms in three languages needs either several rows or extra columns. The format cannot express the relationship between those rows. The reader or the importing tool must infer it.

 

Criterion

TBX

CSV

Standard

ISO 30042:2019, XML-based

None for terminology

Data model

Concept entry, language sections, terms

Flat rows and columns

Synonyms and variants

Native, inside one entry

Extra rows or columns by convention

Metadata (status, part of speech, usage)

Defined data categories

Any column, defined by the team

Human editing

Needs a terminology tool or XML editor

Any spreadsheet

Import into a new tool

Direct, with validation

Column mapping required

Audit suitability

High, structure is machine-checkable

Depends on discipline

How well do TBX and CSV work across tools?

 

TBX is the interchange format for terminology between computer-assisted translation (CAT) tools. Microsoft documents that it can be used to move a terminology list from one CAT tool to another. CSV imports may need column mapping and configuration of language and status fields.

 

Large public repositories offer both. The EU terminology database IATE provides downloads in TBX (ISO 30042) and CSV. That pairing reflects the two real use cases: standard-compliant exchange and spreadsheet access for reviewers.

 

For regulated or high-stakes content, a CSV import usually requires a formal setup phase. The team must map columns and define system fields such as status and language for every term column. Without that step, the same file can load differently in two systems.

 

Some tools use their own native glossary formats. The open-source Anchovy tool, for example, lets users create and edit glossaries and convert formats, while its native GlossML format is not intended for full terminology exchange. Native formats are a third option, but they tie the glossary to one tool.

 

What are the steps to choose and run a term base format?

 

Each step has an owner and a control. The owners below are typical roles, not fixed titles.

 

  1. Inventory the term sources. Owner: localization manager. Control: a register listing every glossary, its format, its language pairs and its approver.

  2. Define the data categories. Owner: terminologist with the regulatory affairs lead. Control: a written field list covering term, language, definition, status, domain, source of the term and approval date.

  3. Select the master format. Owner: localization manager. Control: a decision record naming the master format and the reason. For regulated content, hold the master as a TBX file or in a terminology tool that exports valid TBX.

  4. Define the CSV profile, if CSV is used. Owner: terminologist. Control: a template with fixed column names, fixed language codes, a status vocabulary and UTF-8 encoding.

  5. Validate on import. Owner: localization engineer. Control: schema validation for TBX files, and a row count and sample comparison for CSV files.

  6. Approve terms. Owner: subject-matter expert. Control: status field values such as proposed, approved and deprecated, with a named approver.

  7. Log changes. Owner: terminologist. Control: an audit trail recording who changed which entry and when, plus version-controlled exports.

  8. Restrict access. Owner: information security lead. Control: access control by role, so that only terminologists can edit approved entries.

  9. Run QA against the term base. Owner: linguistic QA lead. Control: automated terminology checks on every deliverable, with exceptions reviewed by a person.

 

What decision criteria separate TBX from CSV?

 

Number of tools and vendors. Two or more tools, or any external vendor, favor TBX. A single internal tool and a single editor can make CSV workable.

 

Entry complexity. Synonyms, definitions, usage notes, forbidden terms and several target languages per concept favor TBX. A plain list of source and target pairs fits CSV.

 

Regulatory exposure. Content that supports medical device, pharmaceutical, legal or financial submissions needs traceable terminology. TBX with status and source fields supports that. CSV can reach the same level only with a strict profile and extra checks.

 

Reviewer skills. Subject-matter experts often prefer a spreadsheet. CSV, or an Excel view generated from TBX, lowers the barrier for review. The master should still remain structured.

 

Language coverage. Character encoding matters for non-Latin scripts and accented text. CSV files can use different encodings, which leaves interpretation ambiguous and causes problems in Excel for many languages. TBX is XML, so the encoding is declared in the file.

 

Lifecycle. A glossary that will grow, be audited or be reused in future systems favors TBX. A throwaway list for one project favors CSV.

 

Subset choice. If full TBX is more than the team needs, TBX-Basic offers a smaller structure designed for translation-oriented terminology.


What decision criteria separate TBX from CSV?

What do real use cases look like?

 

Example 1: A medical device manufacturer with three vendors. The company keeps approved terms for instructions for use in one terminology tool. It exports TBX to each vendor. Each vendor imports the file into its own CAT tool. The status field blocks deprecated terms. CSV is used only for a reviewer sheet sent to clinical staff.

 

Example 2: A law firm with a 400-term glossary. One paralegal maintains the list in a spreadsheet. The team uses one CAT tool. The template has five fixed columns and UTF-8 encoding. CSV is sufficient. The firm keeps a dated copy of each version.

 

Example 3: A bank consolidating legacy glossaries. Four business units hold glossaries in different spreadsheets. The localization team defines a common field list, converts the sheets with a mapping document, validates the output and stores the result as TBX. The old spreadsheets are archived and marked read-only.

 

Example 4: Public terminology as a seed. A team downloads a subject-specific extract from a public repository. IATE offers both TBX and CSV downloads. The team loads TBX to keep the structure and uses CSV only for quick filtering.

 

How does conversion between CSV and TBX work, and what can go wrong?

 

Open-source tools exist for the conversion. The Translate Toolkit includes csv2tbx, a tool to create TBX files from CSV files. The tool depends on the input following the shape it expects.

 

A generic converter for arbitrary tabular files is not possible. The column meaning cannot be known in advance. Every conversion therefore needs a mapping from each column to a TBX data category. Without a mapping document, the output is a guess.

 

The table lists common failure modes and mitigations.

 

Failure mode

Effect

Mitigation

Mixed or unknown encoding

Garbled accents and non-Latin characters

Save as UTF-8, test with a sample row in each language

Unmapped columns

Metadata silently dropped

Written column-to-category mapping, reviewed before conversion

Synonyms split across rows

Duplicate concepts, broken relationships

Assign a concept ID column and group rows before conversion

Missing status values

Deprecated terms treated as approved

Controlled status vocabulary, import rejects empty status

Commas or quotes inside fields

Shifted columns

Quote all fields, compare row counts after import

Spreadsheet auto-formatting

Altered values, such as dates or numbers

Treat all cells as text, review in a plain text editor

Uncontrolled edits

Unapproved terms reach production

Access control by role, audit trail, version-controlled exports

Invalid TBX output

Target tool rejects or misreads the file

Validate the file after conversion and run a test import

One further point applies to any format. Run a round trip test before a large migration. Export, convert, import and compare the entry count and a sample of entries. Record the result in the project file.

 

Where does AD VERBUM fit?

 

AD VERBUM is a language service provider with 25+ years of experience. It integrates client Translation Memories and Term Bases into its workflow. It delivers AI+HUMAN hybrid translation on a proprietary LangOps System hosted on EU servers, with subject-matter expert review. Its certifications include ISO 17100, ISO 18587, ISO 27001 and ISO 42001, audited by Bureau Veritas. Format-specific import and export support for TBX and CSV is [VERIFY] with the vendor.

 

Perspective

 

Terminology is a controlled asset, and the format decides whether the control survives a handoff. In our work with regulated content, we treat the term base as a governed record, not a convenience file. We favor a structured master format, a defined field list and an approval status on every term.   CSV has a place. It is a good review surface for subject-matter experts. Problems start when a spreadsheet becomes the only copy. Then nobody can show which version was approved or why.   Our AI+HUMAN hybrid approach depends on the client’s own terminology. The model applies the term base. The linguist and the subject-matter expert check that it was applied correctly. A clean TBX file makes that check faster and easier to audit.   Eric Brown

 

How can a team put this into practice with a provider?

 

A team that wants its glossaries migrated, validated and applied across languages can brief a provider on the field list, the master format and the approval workflow. AD VERBUM offers translation, localization, interpretation, multilingual SEO, voice over and multilingual documentation. Pricing is quote-based. See the AD VERBUM services page to request a project scope.


AD VERBUM

What are the key points?

 

  • TBX is an XML-based ISO standard (ISO 30042:2019) for terminology exchange. CSV has no terminology standard.

  • TBX stores concepts, language sections and terms. CSV stores flat rows.

  • Use TBX for multiple tools, multiple vendors, audits and long-lived term bases.

  • Use CSV for small, flat glossaries and for reviewer sheets.

  • CSV imports need column mapping and fixed language and status fields.

  • CSV to TBX conversion needs a written mapping, because column meaning is not known in advance.

  • Encoding errors are a common CSV risk. Save as UTF-8 and test every language.

  • Controls that apply to both formats: access control, audit trail, status values and QA against the term base.

 

FAQ

 

What does TBX stand for?

 

TBX stands for TermBase eXchange. It is an XML-based international standard, ISO 30042:2019, for exchanging structured terminological data between software applications. It is documented in Microsoft’s localization file format guide.

 

Can I use CSV instead of TBX for a glossary?

 

Yes, for a small, flat glossary used in one tool by a few editors. Define fixed columns, language codes, a status vocabulary and UTF-8 encoding. For regulated content shared with several vendors, keep a TBX master and export CSV only for review.

 

Is TBX the same as XML?

 

TBX is a specific XML-based format. It defines how concepts, languages, terms and data categories are arranged. A generic XML file has no such rules. TBX is also modular, so subsets such as TBX-Basic exist.

 

What can be lost when converting CSV to TBX?

 

Unmapped columns, synonym relationships and status values are the main risks. Encoding problems can also corrupt characters. A conversion needs a column-to-category mapping, because a generic converter for arbitrary tables is not possible. Validate the output and test an import before use.

 

Sources

 

 
 
bottom of page