How to Convert a Translation Glossary Between CSV TBX and Excel Formats

Almost every terminology handoff we've watched go sideways went sideways at the same point: the file arrived in one format and had to be used in another. The client exports from MultiTerm and gets a TBX. The freelancer's tool wants a two-column CSV. The project manager keeps the master list in Excel because that's the only file the client's engineer will actually open. Learning to convert a translation glossary between CSV, TBX, and Excel is unglamorous plumbing, and it decides whether a term list gets used or quietly ignored. The conversion itself is trivial. Deciding what to throw away is not, because these three formats do not hold the same kind of information at all.

What each format actually stores

CSV is a table and nothing else. Rows, columns, a header line if you're lucky. It has no concept of a term entry, no language sections, no status. Whatever meaning your columns carry lives in your head or in a separate document.

XLSX is that same flat table plus a presentation layer. Merged cells, fill colors, cell comments, multiple sheets, a frozen header row. Terminologists lean on that layer constantly. Yellow means "client hasn't approved this yet." Strikethrough means "we stopped using it in 2024." A comment on cell C412 explains why the German term differs in Austria. None of that survives an import. Importers read text, not formatting.

TBX is a different animal. It's an XML format standardised as ISO 30042, originally developed under LISA, and it's concept-oriented rather than term-oriented. One entry represents a concept. Inside it sit language sections, and inside each language section sit one or more terms, each of which can carry its own part of speech, term type, usage status, context sentence, and note. Above all of that you can hang subject fields, customer fields, and cross-references between entries.

The mismatch is structural. TBX is a tree; CSV and XLSX are tables. Going one direction you flatten a tree, and flattening always throws something out. Going the other direction you have to invent a tree from a table, which means guessing.

We ran into the sharp version of this on a legal glossary a client sent as TBX. One concept held three English terms: one marked preferred, two marked deprecated because the firm had changed house style. Flattened to CSV with one row per term, all three arrived as ordinary entries. The translator picked one of the deprecated ones. It was first alphabetically.

How to convert a translation glossary between CSV, TBX, and Excel without breaking it

Work backwards from the destination. Before touching the file, open the tool that will consume the glossary and find out exactly what its importer accepts, including which version. Some CAT tools read TBX directly. Some want their own proprietary termbase and offer a converter that ingests Excel. Some accept a spreadsheet with a column-mapping dialog. The answer changes between releases, and guessing costs an afternoon.

Then normalise to a flat working table before you do anything else. Whatever the source format, get the content into Excel or a CSV you can read, because that's the only place you can see all the data at once and fix it by hand. Do the cleanup there: deduplicate, resolve conflicting targets, strip stray whitespace, decide what each column means.

Convert out to the destination format last, and once. The single most common way we see glossaries degrade is chained conversion: TBX to CSV, CSV to Excel, Excel back to CSV with different settings, CSV to TBX. Every hop silently drops or mangles something, and by the fourth hop nobody remembers what the original contained.

One more habit worth building: keep the original file. Not a copy of the cleaned version, the actual file the client sent, untouched, in a folder next to the working one. When a term dispute surfaces four months later, the question is always "what did they originally send us," and a chain of overwritten conversions cannot answer it.

If your glossary is going to feed an AI translation step rather than a CAT tool, the format question mostly evaporates. Models read plain text. What matters there is which terms you include and how you phrase the instruction around them, which is a separate problem from file conversion and one we've written about in the context of how AI tools have reshaped translation work.

The CSV problems that quietly break a glossary import

Encoding is the first one and the most common. Excel's plain "Save as CSV" on some Windows builds writes the system codepage instead of UTF-8, so Cyrillic, CJK, and accented Latin characters arrive as mojibake. Use "CSV UTF-8" explicitly. If you see sequences like Ã, Ð, or a stray  at the start of the file, you already have the problem.

Delimiters come second. Whether Excel writes commas or semicolons depends on the machine's regional settings, so a file produced on a German-locale laptop is semicolon-delimited and looks perfectly normal to its author. An importer expecting commas reads each line as a single field and imports a glossary with 2,300 source terms and 2,300 empty targets. We've watched exactly that happen with an automotive termbase, and the person who built it was certain the file was fine, because on their machine it opened correctly.

Quoting bites when terms contain the delimiter. "Charging, rapid" needs to be quoted or it becomes two columns. Definitions containing line breaks need quoted multi-line fields, which a surprising number of importers handle badly.

Then there's whitespace. Trailing spaces, double spaces, and non-breaking spaces pasted in from a Word document all produce terms that look identical on screen and compare as different. An importer stores "valve " and "valve" as two entries; QA later fails to flag a missing term because it's matching against the version with the space.

None of these are exotic. All of them are invisible when you open the file to check it, which is why they get through.

What you lose flattening TBX into a table

Not everything in a TBX deserves to survive, and pretending otherwise produces a spreadsheet with 22 columns that nobody maintains. Decide deliberately.

Keep the concept ID as your first column. It is the only thing that makes a later round trip possible, and it costs one column. Without it, reassembling concepts from a flat sheet is guesswork.

Keep usage status. Preferred, admitted, deprecated: this is the field whose loss causes actual mistranslations, as in the legal glossary above. If your target format has no place for it, add a plain "status" column and tell whoever receives the file what it means.

Keep the subject or domain field if the glossary spans more than one domain. A single sheet mixing contract terminology with plant equipment terminology, with no way to tell which is which, produces confident wrong choices.

Definitions are usually worth keeping. Context sentences usually are not, unless the glossary is being used for review rather than lookup, in which case they're the most useful column in the file.

Cross-references between concepts, embedded images, and external links do not survive at all. Accept it rather than trying to encode them into a cell.

Then decide your row model. One row per concept with only the preferred terms is readable and lossy. One row per term with a concept ID and a status column is close to lossless and much uglier. Pick based on who opens the file. If it's a client's engineer who has never seen a termbase, the first. If it's a terminologist who will convert it back, the second.

Whichever you choose, put a note in the file recording what you dropped. A separate sheet named "conversion notes" with three lines in it has saved us more time than any tool.

Building a valid TBX from a spreadsheet

Going up in structure means creating information that wasn't there, and that's where the failures come from.

You have to group rows into concepts. If your sheet has no concept ID, you're deciding whether two rows sharing an English term represent one concept with two target variants or two genuinely different concepts. Usually it's the former, but "usually" is doing real work in that sentence, and homonyms in technical glossaries are common enough to check.

Language codes have to be valid tags. Not "English" and "German" but en-US and de-DE, and consistently. The most frequent TBX rejection we see is a mismatch between the language declared in the file header and the codes used in the language sections. An HR glossary we converted last year was bounced by the client's importer because the header said en while the entries said en-GB. The file was otherwise perfect and the error message said nothing useful.

Pick your dialect. TBX-Basic covers what most CAT tool importers actually read. The full ISO 30042 specification permits considerably more, and a file that uses the extended feature set may validate correctly and still be rejected downstream. When in doubt, produce the simpler thing.

Validate before you hand it over. TBX that opens fine in a text editor can still fail schema validation, and importers tend to report this as a generic failure. Running the file through a validator takes a minute and turns a mystery into a line number.

On tooling: the Trados ecosystem's Glossary Converter handles the common Excel-to-termbase route and is the path of least resistance if you're already in that world. If you're converting regularly, a short Python script using an XML library gets you a TBX-Basic writer in well under a hundred lines, and the real gain isn't the code, it's that the process becomes repeatable and you stop making a different set of decisions every time.

Checking the converted glossary before anyone imports it

Count terms before and after. If the source had 1,847 entries and the output has 1,832, something was dropped silently, and it will not announce itself later.

Open the last row. Truncation almost always shows up at the end of a file, and a converter that stopped early usually produced valid output for everything before that point.

Search the whole file for encoding damage. The à / Р/  signatures again. Do this on the converted file, not the source, because conversion is where it usually gets introduced.

Count empty target cells. Some will be legitimate, most will not.

Look for duplicate source terms with conflicting targets. Conversion doesn't create these, but flattening makes them visible for the first time, and it's much cheaper to resolve them in a spreadsheet than to have every occurrence flagged in a QA report after translation.

Then do the only check that really settles it: import the file into the destination tool on a throwaway project and translate one paragraph that you know contains three or four of the terms. Two minutes of work that catches the failures the counting checks miss.

A medical glossary we converted from TBX to XLSX passed every count. Same number of rows, no encoding problems, all targets populated. About forty of those targets contained the literal string "None", because the converter had written out a Python null value as text. Nothing in the file structure was wrong. The content was just quietly nonsense, and only opening it in the tool made that obvious.

A routine worth reusing

Six steps, in this order: check what the destination importer accepts; export the source to a flat table; decide the row model and which fields you're keeping; clean the data in the spreadsheet; convert once to the destination format; verify with counts plus a live import test. Keep the untouched original and a conversion-notes sheet alongside the working file.

If the actual problem is that no glossary exists yet, that's a different job. We built a free Glossary Generator for it, which produces a bilingual term list you can paste straight into the spreadsheet you'll be converting from. Inside SnapIntel projects the glossary is editable text you review and approve before translation starts, so the format question doesn't arise for that step. You'll still want a proper termbase in your CAT tool, and the conversion work above is how you get one.

The concrete thing to do next: add two columns to whatever master glossary you maintain right now. A concept ID, and a status field with values you've actually defined. Your current tool will probably ignore both. Every conversion you do after that becomes reversible, and reversible is the property that turns a glossary into something you can still trust in three years.