How to integrate AI translation into an existing CAT tool workflow

Most of the translators and project managers we talk to are not shopping for a new editor. They have Trados, memoQ or Phrase, years of translation memory behind them, and clients who send files in packages built for those tools. Their question is narrower than the one tool comparisons answer: how to integrate AI translation into an existing CAT tool workflow without pulling anything out. We like that question better, because the constraint does most of the design work for you. You are not picking a platform. You are picking where one step goes, what it is allowed to overwrite, and how you find out when it gets something wrong.

Where the AI step belongs in a workflow you already have

An AI translation step fills one slot: the gap between an empty target column and a draft worth editing. It does not replace your TM, your termbase, your QA profile or your reviewer.

That slot already has a name in every CAT tool. Pre-translation is where you apply what you already own to a file before anyone types: exact matches from translation memory, fuzzy matches above your threshold, termbase hits, and whatever MT engine is wired into the project settings. Adding AI means adding one more source and deciding where it sits in the priority order.

We end up recommending the same order almost every time. TM first, AI second, human last. TM segments were approved by a person for this client, so nothing a language model produces should sit on top of them. AI fills what is left. The human edits that output and confirms it back into the TM, which makes the next file in the same account cheaper to run.

Not much changes in practice. Project templates stay. QA profiles stay. Delivery formats stay. What changes is that the first pass over new segments comes from a model that can see the whole document instead of a segment-level engine that cannot, and that the quality of that pass depends on the instructions you write rather than the engine you picked two years ago.

This works best when files arrive in a repeatable shape. An agency that receives DOCX manuals from four industrial clients every month can build the handoff once and run it fifty times. If every project is a one-off with a different source format and a new language pair, the setup cost per project will eat most of the gain, and you are better off with the MT plugin that came with your tool.

How to integrate AI translation into a CAT tool without switching editors

Four mechanics cover almost everything we see in the field, and they are not equally good.

The built-in MT engine or plugin

The lowest-effort option. You select an engine in project settings and pre-translate. No new file handling, no new habits. The cost is control: segment-level output with no document context, no prompt, and usually no reliable way to make the engine respect a glossary.

Pre-translation on the source file, before import

You translate the DOCX, XLSX or PPTX outside the CAT tool, then bring the translated file in for review or align it against the original. Fast for bulk work, and formatting survives better than with segment-level output, because the AI pass sees headings and tables as structure. The weakness is that your TM sat out the first pass.

The bilingual round trip

Export your source segments, run AI translation on them, bring the translated pairs back as a bilingual file, and keep working in the editor. This is where most agencies land. TM and termbase stay authoritative, the AI step is auditable because you can diff what came back, and the translator works where they always worked. It costs two file operations per project.

API glue

A script that posts segments to a model and writes results back through your tool's API. Worth building if you run the same pair and domain every week. Not worth building for five mixed projects a month, and someone has to own it when the API changes under you.

Keeping the translation memory in charge

The failure we see most often is an AI pass that quietly overwrites approved work.

One agency ran a 62,000-word German to English set of quality manuals for a client they had served for years. The client TM covered a little under a quarter of the content, mostly boilerplate: safety warnings and the standard document revision table. On the first attempt the team pre-translated everything with AI and applied TM afterwards, which produced a file where the approved warning wording appeared in three variants depending on which segment the model had rephrased. The reviewer spent most of a day undoing it.

The fix was an ordering rule, not a tool change. Pre-translate from TM first at 100% and at your fuzzy threshold, lock those segments, then send only the unlocked rows out for AI translation. In memoQ and Trados that is a filter and a lock; in Phrase it is a job-level pre-translation setting. Call it thirty seconds of setup per project.

Two things follow. The AI step gets cheaper, because you stop paying to translate segments you already have. And your TM stays a record of decisions a human made, which matters the first time a client asks why a term changed between two deliveries.

One caveat, because locking has a failure mode of its own. A 100% match is not always right. If the client updated their terminology last quarter and the TM still carries the old term, locking propagates it faithfully. We tell teams to run the termbase check across locked segments too, rather than only across new ones. The lock protects approved work from the model. It does not protect it from being out of date.

Glossary and prompt before the run, not after

A model follows instructions better than it follows corrections. Anything you would otherwise fix in post-editing is cheaper to state up front.

Two inputs do most of the work. A glossary: the terms that must come back a specific way, with the client's preferred target for each. And a prompt that names the domain, the audience, the register, and the handful of conventions this client cares about. US or UK spelling? Measurements converted or left as written? Formal or informal second person for this market?

A freelancer we talked to translates Spanish to English price lists and product specifications for an industrial distributor, usually XLSX workbooks of a few hundred rows. Her early AI runs came back with "junta" rendered as seal, gasket and joint inside the same sheet, which is the kind of inconsistency a reviewer catches slowly and a client catches immediately. She now keeps a 40-term glossary for that account and a six-line prompt naming the equipment category and telling the model to prefer the shorter trade term. The terminology problem went away. The register in the marketing blurbs at the bottom of each sheet did not, and she still rewrites those by hand.

That is the honest shape of it. Glossary and prompt fix terminology drift and most register mismatches. They do nothing for ambiguity in the source, and nothing for numbers. If the source says 10 working days and the model writes 10 days, no glossary entry prevents it. That is what QA is for.

The formats that make or break the handoff

Whatever pattern you pick, the AI step has to hand you something your CAT tool reads without a fight. Three formats cover it.

TMX is the interchange format for translation memories, and every serious CAT tool imports it. If what you want is AI-translated content sitting in a TM so it comes back as matches on future projects, TMX is the route.

XLIFF is the bilingual exchange format for files in progress, standardised by OASIS. It carries segmentation, state and metadata, which makes it the cleanest round trip when your tool exports it. It is also the least forgiving: a file that fails validation fails completely.

A plain source/target XLSX is the format that actually gets used, because it opens anywhere and a human can inspect it. Two columns, one segment per row, source left and target right. Trados, memoQ and Phrase all import bilingual Excel through a column mapping step, and the mapping details are written up in our guide to importing a bilingual Excel file into Trados, memoQ and Phrase. If what you are building is the pre-translation step itself rather than the import, our walkthrough of an AI pre-translation step that works with any CAT tool covers the ordering in more detail.

One practical warning about XLSX handoffs. Segment counts have to match on the way back. If your export had 1,842 rows and the file you get back has 1,839, something merged segments during translation, and re-aligning by hand is worse than running the step again.

QA that catches what pre-translation gets wrong

AI output fails differently from human output, so the checks have to shift.

Human translators make errors of understanding, and those tend to leave a trace: an awkward sentence, a hedge, a query in the file. Models produce fluent text that is wrong in specific, boring ways. In our own runs the recurring categories are numbers, negation, omission and terminology drift. A dropped "not" reads perfectly. A unit written as mm instead of cm reads perfectly. Those are the errors that reach a client.

So run the mechanical checks first, and run them hard. Your QA profile already covers number consistency, termbase violations, empty targets and length anomalies. Turn all of them on for AI-pretranslated jobs, including the ones you normally mute because they are noisy on human work. Then read the output where the stakes are: obligations, tolerances, dates, anything with a quantity, anything with a negative in it.

The second check is sampling. On a 50,000-word job nobody rereads everything against the source. Pull 500 to 1,000 words from three different parts of the document, compare them segment by segment, and log what you find by category. If the errors cluster in one category, the prompt or the glossary usually fixes the rest of the file. If they are scattered, the pair or the domain is past what the model handles reliably, and the job needs full post-editing rather than a light pass. ISO 18587 defines those post-editing levels if you want wording your clients recognise in a quote.

If you want the AI step itself to produce that evidence rather than leaving you to assemble it, that is roughly what we built SnapIntel for. You upload a DOCX, XLSX or PPTX, prepare and approve a glossary and prompt before translation starts, and get back the translated file plus a QA report, a quality rating, and a neutral source/target XLSX export you can import into any CAT tool. There is no integration with any specific CAT tool, by design. The XLSX is the handoff. More at snapintel.io.

A pilot you can run on one project this week

Pick a real project you would otherwise run normally. Mid-sized, a pair you know well, a client whose preferences you can state out loud without looking them up.

Then:

1. Pre-translate from TM at 100% and at your fuzzy threshold. Lock those segments.
2. Export the unlocked segments as bilingual XLSX.
3. Write the glossary (20 to 40 terms is enough to start) and a prompt of five or six lines naming domain, audience and spelling convention.
4. Run the AI pass on the export only.
5. Import the returned pairs with TM priority above the imported target.
6. Run the full QA profile, then sample 500 words against the source and log errors by category.
7. Record editing time and compare it with your baseline for that client.

One project tells you whether the handoff is clean. Three tell you whether the time saving is real, because the first one carries setup you never repeat. If the numbers have not moved after three, the honest reading is that your TM was already doing the work and the AI step has nothing left to fill.