How to Import a Bilingual Excel File into Trados, memoQ, and Phrase

A client sends a spreadsheet with English in column B, German in column C, and 4,200 rows underneath. They want to know whether you can "just reuse it." Or an AI translation run hands you a source/target workbook and you want that content sitting in the project TM before anyone starts reviewing. Either way the question is the same: how do you import bilingual Excel into a CAT tool without the pairs sliding out of sync or half the rows vanishing.

All three tools most agencies run on can do it. Trados Studio, memoQ, and Phrase TMS each have a filter for exactly this. None of them handle it the same way, and each one has a step where people quietly lose an afternoon. We've watched this go wrong often enough to write down what actually matters.

What a bilingual Excel file actually is

There is no standard here. That's the first thing to accept. TMX has a schema. XLIFF has a schema. "Bilingual Excel" just means somebody put source segments in one column and their translations in another, and everything else about the file is a local convention.

The variations are endless in practice. Some files have an ID column that maps back to a CMS. Some have a comment column with reviewer notes. Some have a status column with values like "approved" or "needs check." Some have the language codes in row 1, some in row 3, some nowhere at all. A file from a software client might have the target column split across four languages side by side. A file from a manufacturing client is usually two columns and a part number.

CAT tools don't guess any of this. What they give you instead is a filter where you declare the layout: source is column B, target is column C, skip the first row, treat column E as context. Get the declaration right and the import is boring. Get it wrong by one column or one row and you produce a translation memory full of confidently mismatched pairs, which is worse than having no TM at all, because a wrong 100% match gets accepted without thought.

This is also why bilingual Excel is a poor archival format and a fine transport format. Once the content is inside your tool, export it to TMX and keep the TMX. The spreadsheet was scaffolding.

Clean the spreadsheet before you open the import dialog

Most failed imports are failed spreadsheets. Ten minutes in Excel saves an hour of forensic work later.

Flatten the formulas first. If the target column contains VLOOKUP or CONCATENATE results, select the column, copy, and paste as values. We once had a price-list import where the target cells pulled from a lookup table on a second sheet, and the CAT tool read the cached values from the last time the client had opened the file. About sixty rows were stale by two revisions. Nobody noticed until the reviewer flagged a discontinued product name.

Then kill the merged cells. Merged cells are the single most common cause of row-count drift, because a cell merged across three rows collapses into one value and everything below it shifts. Unmerge, fill the gaps, check that your source and target columns both report the same number of non-empty cells. In Excel, =COUNTA(B:B) next to =COUNTA(C:C) takes five seconds and tells you immediately whether the file is aligned.

A few more things worth doing in the same pass. Delete rows where the target is empty, because empty targets become empty translation units that clutter fuzzy match results later. Delete rows where source and target are identical, unless they genuinely should be, since untranslated placeholders inflate your match statistics. Trim leading and trailing spaces, which survive import and cause 99% matches instead of 100% ones. And if numbers appear in either column, check whether Excel stored them as numbers rather than text, because 1,250.00 in the source and 1.250,00 in the target are formatting the tool will not reconcile for you.

Finally, put everything on one sheet. Multi-sheet bilingual files import inconsistently across tools, and splitting them yourself is faster than debugging why sheet 3 came in blank.

How to import bilingual Excel into Trados Studio

Trados has a dedicated Bilingual Excel file type. It lives under Options, then File Types, alongside the regular Microsoft Excel filter, and it is switched off in some installations, so check it's enabled and sitting above the standard XLSX filter in the priority order. If plain Excel is higher in the list, Trados will use that instead and you'll get every cell as a separate translatable segment, source and target both.

The settings you care about are the column letters. Set the source column, set the target column, and set the first row that contains content rather than headers. There are optional slots for a comment column and a context column, and both are worth filling if the client gave you that data, because comments come through as segment notes and context keys help Trados distinguish otherwise identical strings.

Add the file to a project as a translatable document. Trados opens it with the target column already populated, usually as draft segments. Confirm the rows you trust, fix what you don't, and then run the batch task that updates the main translation memory. Segments only reach the TM once they're confirmed, which is the safety net: you get a review pass before anything permanent happens.

The friction point is that the file type configuration is global rather than per-project. Change the column mapping for one client's layout and the next file that arrives with a different layout imports wrong. Agencies handling several clients usually duplicate the file type, rename each copy after the client, and switch the active one before importing. It's clumsy, but it beats discovering the mismatch after the TM update.

If what you have is two separate monolingual documents rather than a spreadsheet, this filter is the wrong tool. Use Trados Alignment instead and let it pair the segments.

How to import a bilingual Excel file into memoQ

memoQ handles this through the multilingual delimited text filter, which despite the name reads XLSX as well as CSV. Import the file, and when the filter selection appears, choose that one rather than the plain Excel filter.

The mapping dialog is more capable than the Trados equivalent. You assign a role to each column: source language, target language, ID, comment, context. If the file carries four target languages in four columns, you can map all of them and memoQ will create separate documents per language pair. There's a checkbox for whether the target column arrives as translated content or as empty, and one for the segment status the imported rows should carry.

Once the document is open, confirming rows writes them into whichever TM is set as the working memory for the project. Use "confirm and update rows" if you want to push a whole reviewed batch at once.

The choice worth thinking about here is TM versus LiveDocs. Everything above assumes the content is good enough to become translation memory. Often it isn't. A legacy spreadsheet from a client with no version history, or output from an unknown MT engine, is reference material rather than a source of 100% matches. Put that content in a LiveDocs corpus instead. You still get fuzzy hits and concordance lookups while working, but nothing auto-propagates into new translations. We suggest this whenever the provenance of a bilingual file is unclear, and it has saved more than one project from inheriting somebody else's terminology decisions.

How to import bilingual Excel into Phrase TMS

Phrase calls its filter multilingual XLSX, and you configure it in the file import settings before creating the job rather than during import. Build a named import setting for the layout, save it, and reuse it.

The fields are familiar: source column, one or more target columns, a context key column, a note column, and the number of header rows to skip. Phrase also offers a maximum-length column, which matters for UI strings where the client has hard character limits. When you create the job, select the saved import setting and pick target languages that match your column mapping. A mismatch between the job's target language and the mapped column is the error we see most often in Phrase, and it produces a job that imports cleanly but empty.

Segments arrive pre-filled. Confirming them writes to the project's translation memory, provided that TM is attached in write mode. Read-only TMs accept nothing, silently, which catches people out on projects where a client-owned TM is attached for reference alongside a working one.

Phrase also accepts TMX directly into a TM, bypassing the job entirely. That's the faster route when the content has already been reviewed and you only want it available as matches. It skips the review step, so use it only for content you trust.

The conversion route when the filters fight you

Sometimes the tool refuses to cooperate, or you're working in something without a bilingual spreadsheet filter at all. The fallback that always works is converting the spreadsheet to TMX and importing the TMX into the translation memory.

The conversion itself is mechanical. Heartsome TMX Editor is the open-source option people still reach for. A short Python script over openpyxl works too, and if you're doing this monthly it's worth the hour to write one, because you control exactly which rows get skipped and what metadata goes into each translation unit.

The tradeoff is real and worth naming. Going straight to TMX means the content enters the TM without passing through an editor, so nobody looks at it first. There's no confirmation step, no place to catch the forty rows where the target column holds a comment instead of a translation. For content you've already reviewed, that's fine and fast. For content of unknown quality, the filter route with its confirmation gate is the safer path even though it takes longer. We keep a rough rule: if you can't say who translated it and when, don't let it reach the TM unreviewed.

What breaks, and how to catch it in two minutes

Row offset is the classic failure. The header row gets treated as content, every pair shifts by one, and you end up with a TM where each English string is stored against the German translation of the previous string. The insidious part is that it looks fine at a glance because both columns contain plausible text.

Segment count mismatch is the second. A merged cell, a stray blank row in one column only, or a manual line break inside a cell that the filter treats as a segment boundary. In a 12,000-row product catalogue we worked through last year, roughly 400 rows had blank targets that the client had never filled in. Those imported as empty translation units and later surfaced as 100% matches with nothing in them, which reviewers kept "fixing" by retyping content that was already elsewhere in the file.

Tags and placeholders are the third. Strings like {count} or %s or <b> arrive as literal text rather than protected elements, so they're editable, deletable, and translatable. Nothing stops a translator from localizing {count} into {anzahl} and breaking the build.

The check takes two minutes. After import, look at the first three segments, the last three, and three from the middle. Read the source, read the target, confirm they belong together. Then sort or filter for empty targets and for segments where source and target are byte-identical. If those three checks pass, the import is almost certainly sound. If the first-and-last check fails, delete the document, fix the spreadsheet, and import again rather than trying to repair it in the editor.

Where a neutral spreadsheet export fits an AI workflow

The reason this topic keeps coming up is that AI translation and CAT tools now meet at a spreadsheet more often than at any file format either side designed. An AI step produces source and target pairs. The CAT tool needs those pairs in its TM. A two-column XLSX is the least opinionated thing that can sit between them.

That's the design choice behind our own export. SnapIntel takes DOCX documents, XLSX workbooks, and PPTX presentations, runs them through a workflow where you set up domain analysis, a glossary, and a translation prompt before anything is translated, and returns the translated file plus a neutral source/target XLSX and a QA report. The spreadsheet isn't tied to any vendor's format. It's the plain two-column layout the filters in this article are built to read, which means the import path is whichever one you already know. There's no integration to configure, because there's nothing to integrate with. You can see how the workflow fits together at snapintel.io, and we've written separately about updating a translation memory with AI-translated content.

This works best when your team already has a review habit. It works badly if the spreadsheet goes straight into a shared TM with no one reading it, which is the same warning as the TMX shortcut above, arriving from a different direction.

Do this once and stop rebuilding it

Pick a canonical layout and force every incoming bilingual spreadsheet into it before import: source in column A, target in column B, headers in row 1, one sheet, no merged cells, no formulas. Build one saved import configuration per tool against that layout, name it something like standard-2col, and never edit it again.

Reformatting a client's file to match your layout takes about five minutes. Rebuilding a column mapping for every incoming variant takes longer than that, and it fails silently when you get it wrong. The five minutes is the cheaper habit.