SnapIntel Neutral XLSX Export: How to Move AI-Translated Content Into Any CAT Tool

A translation job is not over when the translated file lands in your downloads folder. The next question is always where the content goes after that: into a translation memory, onto a reviewer's screen, into a client's own system. The SnapIntel neutral XLSX export is built for that step. Every completed job produces a plain source and target spreadsheet alongside the translated document, with no proprietary packaging and no assumption about which CAT tool you happen to use. This piece covers what sits inside that file, how to get it into Trados, memoQ, or Phrase, what to clean out first, and where the file stops being useful.

What the SnapIntel neutral XLSX export actually contains

The file is a spreadsheet with one row per segment. Source text in one column, the translated text in the next, in document order. That is the design, and the plainness is deliberate.

For a DOCX project the export arrives next to the delivery DOCX. For an XLSX workbook it sits beside the translated workbook, and for a PPTX presentation beside the translated deck. The segmentation matches what the translation step actually saw when SnapIntel normalised your file, not what your own CAT tool would have produced from the same source. Keep that in mind when you compare row counts against a Trados analysis. The numbers will rarely line up exactly, and neither count is wrong.

The QA report and the quality rating are separate artifacts, and they stay separate on purpose. The spreadsheet is the content. The QA report is the opinion about the content. Mixing the two into one file makes both harder to use, because the moment you want to import segments somewhere you have to strip the commentary back out.

What you can do with the export on day one is unglamorous and useful. Open it in Excel or LibreOffice and read the translation next to the source without launching anything. Send it to a reviewer who has never touched a CAT tool and never will. Sort by source text to find repeated strings that came out differently. Filter for rows where the target is identical to the source, which is usually how you spot untranslated fragments in a hurry.

One agency we worked with kept a filtered copy of the export as their internal delivery record. Not the translated DOCX, which a client might later edit, but the spreadsheet showing what was delivered on which date. It answered arguments faster than email threads did.

Why we ship a spreadsheet instead of a vendor format

The obvious question is why the export is not TMX. TMX is the native exchange format for translation memories, and shipping one would save a conversion step for anyone whose workflow is already TM-first.

We looked hard at that and chose the spreadsheet anyway. TMX carries assumptions inside it: segmentation boundaries, language code conventions, an inline tag model, and metadata fields that different tools read differently. When a TMX is slightly wrong, nothing visibly breaks. The import succeeds, the segments land in your memory, and six months later a fuzzy match surfaces a sentence that was never quite right. A spreadsheet fails loudly instead. If a column is off or a row is garbage, you see it before you import anything.

There is also a plainer reason. Not everyone who needs to look at translated content owns a CAT tool. The subject-matter expert at a manufacturing client who actually knows whether the pressure valve terminology is correct is not going to install memoQ to tell you. They will open a spreadsheet, type in the margin, and send it back. We have watched that review loop close in an afternoon when the CAT-tool version of the same loop took a week of licence discussions.

The honest tradeoff: if your process runs entirely on TMX, the export adds a conversion step you did not have before. Most CAT tools can create a TM directly from bilingual Excel, and our guide on updating a translation memory with AI-translated content walks through the route. But it is a step, and pretending otherwise would be dishonest. If you translate the same recurring documents every month and never look at individual segments, TMX would serve you better and you should say so.

How to move the export into a CAT tool

The mechanics differ per tool, and we wrote them up separately in how to import a bilingual Excel file into Trados, memoQ, and Phrase. What matters more than the click path is the three decisions you make before you start.

The first is which column is source and which is target. It sounds trivial until you import a reversed pair into a production memory and spend an evening undoing it. Check the first five rows visually. If your source language is English and the left column reads English, you are fine. Do not trust the header alone.

The second decision is the language code. Spreadsheets carry no locale information, so you assign it at import. A memory built as en-US against one built as en-GB will not talk to each other cleanly later, and neither will es-ES and es-MX. Pick the convention your existing memories already use and stay with it even when it looks wrong.

The third decision is whether this content belongs in a translation memory at all, or in an alignment corpus. Trados calls the second option an alignment, memoQ calls it LiveDocs. The difference is trust. A TM entry is something you are willing to have proposed back to you as a match. A corpus entry is something you are willing to search. Post-edited content that a human reviewed is TM material. Raw AI output that nobody has read yet is corpus material at best, and we would argue it is neither until someone looks at it.

A freelancer we know keeps two memories per client for exactly this reason: one reviewed, one provisional. Provisional entries get promoted once they survive a real project. It costs her about ten minutes per job and has saved her from propagating at least one confidently wrong rendering of a contract clause.

Clean the file before it touches your production TM

A translation memory is a long-lived asset. What goes in stays in, gets proposed back to you for years, and quietly shapes the work of every translator you share it with. That argues for a cleaning pass before import, not after.

Start by deleting rows where the source and target are identical. In technical documents this is usually part numbers, model codes, and standards references that were correctly left alone. They are correct in the document and useless in a memory, where they pad your match statistics without ever helping anyone. On a 9,000-word equipment manual we saw recently, roughly 600 rows were bare alphanumeric codes. Importing them would have inflated the memory by a fifth with content of no reuse value.

Next, look at very short segments. Single words and table-cell fragments carry almost no context, which means a future fuzzy match against them tells the translator nothing about how the term behaved in a sentence. Some teams drop everything under three words. Others keep them but tag them. Either approach beats importing them silently.

Then read the QA report before you decide the run is memory-worthy at all. If the report flags terminology inconsistencies or a low quality rating, importing the segments makes the problem permanent instead of fixing it. This is the part most people skip, and it is the part that determines whether your memory helps you in two years or gradually poisons your output.

A limitation worth naming: none of this applies if you are translating a one-off document that will never recur. Cleaning a spreadsheet to feed a memory you will never query again is busywork. Marketing copy for a single campaign, a board pack for one meeting, a supplier letter that will never be sent twice. Deliver it and move on.

Two workflows where the export earns its place

The first is the freelancer who works with direct clients but delivers to agencies that expect Trados. A client sends a plain DOCX with no package, no memory, no glossary. Running it through SnapIntel produces the translated DOCX for delivery plus the bilingual spreadsheet. She post-edits, imports the corrected pairs into her own client-specific memory, and the next job from that client arrives with real matches behind it. The client never learns any of this, which is the point. She built an asset out of a job that would otherwise have left nothing behind.

The second is an agency handling a client who asks for the translation memory as part of delivery. That request used to mean a conversation about which tool the client owned and whether their version could read the export format. With a bilingual spreadsheet the conversation gets shorter: here are the segments, import them however your system prefers. If the client has no system, they still have a file they can read. We have seen this settle procurement questions that had been circling for weeks.

There is a third pattern we did not expect, and it comes from companies with no translation staff at all. They use the spreadsheet as a review artifact rather than a memory source. The legal team reads the contract clauses side by side, marks two rows they want changed, and sends it back. Nobody in that loop knows what a TM is, and nobody needs to.

If you want the workflow context around all of this, snapintel.io covers the full path: DOCX, XLSX, or PPTX import, domain analysis, glossary and prompt preparation with an approval gate before translation starts, progress tracking during the job, and the downloadable outputs at the end, of which the neutral export is one.

What the export does not carry

The spreadsheet holds text. It does not hold formatting, and it never will, because that job belongs to the delivery file. If you import the export into a CAT tool expecting inline tags, bold runs, or table structure to come along, you will be disappointed. The translated DOCX, workbook, or presentation carries the formatting. The spreadsheet carries the words.

It also carries no match metadata. There are no fuzzy percentages, no segment status, no author or timestamp per row, no revision history. Anything your CAT tool would normally record about how a segment came to exist is absent, because the file was never a CAT tool artifact.

And it does not import itself. We are careful about this claim because the industry is full of tools that promise universal compatibility and deliver a file that technically opens. A neutral source and target spreadsheet is portable in the sense that most tools have a documented path to bring one in. You still run that import, you still set the language codes, and you still check the result. What the format buys you is the absence of a dependency, not the absence of work.

Finally, it is not a replacement for a CAT tool. If you need concordance search across a decade of projects, fuzzy match propagation while you type, or a shared server memory across a team of twelve, that is what CAT tools are for. The export is how AI-translated content reaches them.

A test worth running this week

Take one finished job and spend twenty minutes on it. Open the neutral export, add a helper column comparing source to target, and filter for the identical rows. Delete them. Filter for segments under three words and decide, once, what your policy is. Set your language codes to match whatever your oldest memory uses. Import the rest into a sandbox memory rather than your production one, then run a concordance search on two or three terms you care about and see what comes back.

If the matches read like something you would accept from a colleague, promote the memory. If they read like something you would quietly fix before delivery, you have just learned something about your preparation step rather than about your memory, and the glossary is usually where that gets fixed.

The trial gives you 5,000 words over seven days with no card, which is enough to run one real document end to end and inspect the export properly. Pro is $20 a month for 60,000 words and unlimited documents if the workflow holds up. Either way, run the export through your own tool before you decide it fits, because the only compatibility claim that counts is the one you verified yourself.