How to send an AI-translated file to a reviewer who only has Trados
How to send a translation for review to a Trados user after AI translation: four handoff routes, what each one costs you, and when to pick which.
The file is translated. The glossary held up. The tables and numbered lists survived. Then the client replies: our reviewer works in Trados, can you send it in something she can open? If you have ever had to send a translation for review to a Trados user after translating outside any CAT tool, you know the honest answer is "that depends," and it depends on things nobody writes into the purchase order. Who owns the project. Whether anyone on your side has a Studio licence. Whether you need the reviewer's edits back as reusable data or just as a corrected document.
We get asked about this more than almost any other workflow question, usually by freelancers and small teams who have moved their translation step to AI but still work with clients whose review happens inside Trados. Here is how we think about it, roughly in the order we would try things.
Why this handoff breaks more often than it should
The awkwardness is structural, not technical. Trados Studio is built around the idea that the project starts in Studio. You create the project, Studio segments the source, applies the TM, and from that point every artefact in the workflow (the SDLXLIFF, the package, the return package, the bilingual review export) is a child of that project. Review is one stage inside a container that already exists.
An AI translation step done outside a CAT tool produces something different: a finished target file, plus whatever bilingual data the tool gives you. There is no project. Nobody has segmented the source using Studio's segmentation rules, so nothing you hand over lines up with what Studio would have produced on its own.
That mismatch is where the time goes. We have watched a translator spend most of an afternoon trying to force a translated DOCX into a shape a reviewer's Studio install would accept, when the reviewer could have built the project in four minutes and pre-populated it from a TM. The work was real work. It just solved the wrong problem.
The other thing worth naming early: "only has Trados" usually means the reviewer has Studio and no appetite for learning anything else. That is a legitimate position. Reviewers who edit in Studio get concordance search, QA checks, and the client's termbase in the same window. Asking them to review in Word strips all of that away. So the goal is not to talk them out of Trados. The goal is to get your content into their environment with as little loss as possible, and to get their changes back in a form you can reuse.
What a Trados reviewer actually needs when you send a translation for review
Three things, in descending order of how often people forget them.
First, segment-level alignment. A reviewer in Studio works row by row, source beside target. If your content arrives as a monolingual translated file, Studio has nothing to put in the left column, and the reviewer is proofreading blind. Everything below is really about preserving that pairing.
Second, a project the reviewer can run QA inside. Studio's verification checks for number consistency, termbase violations and missing segments only fire on a real project. A bilingual DOCX opened in Word gives none of that. If your client asked for Trados specifically, QA inside Studio is often the actual reason, even when the email said "format."
Third, a path back. This is the one that gets skipped. Teams plan the outbound handoff carefully and then discover the reviewer's edits exist only inside her Studio project, invisible to the TM they wanted to build. Decide what you need back before you send anything: a corrected target file, a bilingual file with the final text, or a TMX you can import somewhere.
We would add a fourth, softer requirement: tell the reviewer what the AI produced and what it did not. A reviewer who knows the text came from a machine translation step with an approved glossary reviews differently, and better, than one who assumes a human drafted it. In our experience that single line in the handoff email changes the character of the feedback more than any file format choice does.
The cleanest route: let the reviewer own the project
If the reviewer has Studio and you do not, the lowest-friction arrangement is to stop trying to produce Studio artefacts at all. You cannot create an SDLXLIFF or an .sdlppx package without Studio, and the third-party routes that approximate it are fragile. So invert the flow. The reviewer creates the project from the original source file, and you supply the translated content as something Studio can pull in.
In practice that means handing over two things: the untouched source document, and your bilingual source-target data. The reviewer creates a project from the source, imports your bilingual data as a translation memory, runs pre-translate, and lands in a Studio project where every segment is populated with your text and marked as a TM match. From there she reviews the way she always does, with her termbase and her QA profile attached.
Practically every structured AI translation workflow can produce the bilingual half of that. What you want is a two-column source and target export at segment level, not a formatted document. Studio will not read an arbitrary spreadsheet as a TM directly, so this usually means converting your source-target table to TMX first, or using Studio's bilingual Excel file type and treating your export as a translatable file rather than as a memory. Both work. The TMX route is cleaner, because the content ends up in a memory the reviewer can reuse and you can get back.
The limitation is obvious: this needs a reviewer who is willing to set up the project. Some are, especially in-house reviewers at client companies who do this routinely. Agency-side reviewers paid per word for a review task sometimes are not, and that is a commercial conversation rather than a technical one. If you are working with Trados packages regularly, our guide to SDLPPX and SDLRPX packages covers how the container actually moves between parties.
When you have to send the content instead
Sometimes the reviewer will not build a project, and you are left shipping files. The bilingual spreadsheet is the most honest option here, and we reach for it more than anything else.
A two-column XLSX with source on the left and target on the right does three things well. It preserves segment alignment, which is the requirement everything else depends on. It opens anywhere, so the reviewer can at least see the pairing even if she declines to import it. And it comes back to you as structured data you can diff, which matters more than people expect: when the edits arrive in a spreadsheet you can see exactly which 40 of 900 segments changed, instead of re-reading a whole document hunting for differences.
For the reviewer who does want to work in Studio, that same spreadsheet is the import source, either as a TM after conversion or through the bilingual Excel file type. We have a walkthrough of the import side in how to import a bilingual Excel file into Trados, memoQ and Phrase if you need the click path.
Two things to get right in the export. Keep your segmentation stable, because if you later re-export with different segmentation, the reviewer's row-by-row edits stop matching anything. And include a third column for comments. Reviewers write comments whether or not you give them somewhere to put them, and a dedicated column keeps them out of the target text, where they turn into delivered errors. We learned that from a product catalogue where a reviewer's note about an ambiguous SKU description ended up inside a cell and shipped to the client's web team.
Where the spreadsheet route falls down: anything where layout carries meaning. Slide decks are the clear case. A reviewer reading PPTX content as spreadsheet rows cannot see that a sentence she just lengthened by 30% now overflows its text box. For presentations we send the spreadsheet and the translated deck together and accept the redundancy.
The tracked-changes route, and its limits
The other common request is simpler: send the translated DOCX, let the reviewer edit it in Word with track changes on, send it back. Studio handles the inbound side of this well enough, and reviewers who only occasionally review do not need to be onboarded to anything.
It works. It also throws away structure. Tracked changes in a DOCX record edits against the document, not against segments, so you get a file with revision marks and no way to map those marks to a segment ID. Accepting them gives you a corrected document. It does not give you updated TM entries unless you realign afterwards, which is its own small project.
We use this route in two situations. One is a single short document with no follow-on work, where nobody will ever reuse the content and the TM question is moot. The other is when the reviewer is a subject-matter expert rather than a linguist, typically an engineer or a lawyer at the client who will read the translated text and fix the terminology that offends them. Those reviewers are the best source of glossary entries you will ever get, and asking them to work in a CAT tool is how you lose them.
What we have stopped doing is using tracked changes for long documents on recurring accounts. On a 60-page technical manual that gets updated twice a year, a tracked-changes review means every cycle starts from a document rather than from a memory, and the same terminology corrections get made again and again by a reviewer who correctly starts to wonder whether anyone is listening. That is the scenario where the hour spent setting up a proper bilingual flow pays for itself by the second update.
One practical note: if you do send a DOCX for tracked-changes review, lock or clearly mark anything the reviewer should not touch. Field codes, cross-references and auto-numbered lists are easy to break in Word by someone who is paying attention to wording rather than to structure.
Getting the edits back into your files
The return leg is where most of the value sits, and where most workflows stop thinking. Decide up front which of these you need.
If you need a corrected deliverable only, any route works, including tracked changes. If you need reusable bilingual data, the edits have to come back at segment level, which means either a spreadsheet with the reviewer's final text in the target column or a TMX exported from her Studio project. Ask for the TMX in the same email as the handoff. Asking three weeks later, after the project has been archived, tends not to go well.
If the reviewer worked in Studio on her own project, a return package (.sdlrpx) is the standard container, but it is only useful if someone on your side has Studio to open it. If nobody does, ask for a TMX export and a copy of the final target file instead. Both are a couple of clicks for her, and both are readable by you without a licence.
Then close the loop on terminology. Most review edits fall into two groups: genuine corrections, and terminology preferences the reviewer holds and you did not know about. The second group belongs in your glossary, not just in this one file. We run a short pass over returned edits, sort the repeated term changes into the glossary, and feed that glossary into the next job on the same account. It is unglamorous, and it is the single highest-return habit we have seen in teams that mix AI translation with external review.
If you are running this with SnapIntel, the pieces that matter for a Trados handoff are the neutral XLSX export, which is what you hand the reviewer or convert to TMX, and the glossary approval step before translation starts, which is where last cycle's reviewer corrections get locked in so they are not re-litigated. The translated DOCX, XLSX or PPTX comes out alongside a QA report, which gives you something to reconcile the reviewer's findings against. More at snapintel.io.
What we would do by default
Start by asking one question: does this account recur? If a client sends you similar documents more than twice a year, the handoff is worth setting up properly, and the setup is the same every time. Hand the reviewer the original source plus a bilingual source-target export, ask her to build the Studio project and pre-translate from it, and ask for a TMX back along with the final file. Put the repeated term changes into the glossary before the next job starts.
For one-off documents with a non-linguist reviewer, send the translated file and let them track changes in Word. You will lose the segment-level data, and on a one-off you were never going to use it.
The thing not to do is what the awkward middle tempts you into: hand-building Studio artefacts without Studio, or re-typing a reviewer's corrections into your own files by hand. Both feel like diligence. Both are unpaid labour standing in for a five-minute conversation about who owns the project.