SDLPPX and SDLRPX Explained: How Trados Packages Move Between Agencies and Translators
What a Trados package SDLPPX contains, how SDLRPX return packages work, and how to hand files between agencies and translators without losing work.
Open your inbox on a Monday and there it is: a Trados package SDLPPX file, 180 MB, with a one-line note asking for it back by Thursday. No instructions, no separate glossary, no explanation of what's inside. We've watched translators spend twenty minutes just working out which file in the package they're supposed to touch.
The package format solves a real problem. It also creates a specific set of failure modes that show up in nearly every agency we talk to. Here's what these files actually are, how the round trip works, and where it goes wrong.
What's actually inside a trados package sdlppx file
An SDLPPX is a ZIP archive wearing a different extension. Rename it to .zip and any file manager will open it, which is occasionally useful for diagnosis and a bad idea as a working method.
A well-built package carries:
- the .sdlproj project file, which defines languages, file structure and task assignments
- one or more SDLXLIFF bilingual files, the actual working documents
- translation memories (.sdltm) the project manager chose to include
- termbases (.sdltb)
- reference files: style guides, source PDFs, client briefs
- QA verification settings and segmentation rules
- a due date and an assignment record
That last group matters more than people expect. When a project manager configures QA checks in Studio and ships them inside the package, every translator on the job runs the same number checks, the same forbidden-term list, the same tag rules. When they don't, each translator uses whatever profile happens to sit on their machine, and you end up with three different interpretations of what counts as an error.
The TM question is where packages get heavy. A project TM holding only segments relevant to this job might be 4 MB. A full client TM with 300,000 units can be 800 MB. We've seen an agency ship the full TM out of caution and then wonder why a translator on a metered connection burned two days downloading a three-day job. Send a project TM unless the translator genuinely needs concordance search across the client's whole history.
Why the return package is a different animal
The SDLRPX is not a mirror image of the SDLPPX, and the assumption of symmetry trips up a lot of people.
A return package contains the updated SDLXLIFF files and, depending on settings, TM updates. It does not carry the project structure, the termbases or the reference material. It's a delta, not a copy. That's why a 180 MB package usually comes back as 4 MB, and why a small return package is not evidence that the translator did less work than you expected.
The constraint that surprises freelancers: you cannot open an SDLRPX on its own. It imports back into the original project, on the machine where that project lives, and nowhere else. If a project manager deletes the project folder after sending the package out, the return package becomes a container nobody can unpack. Translators have written to us asking how to read an SDLRPX a client sent them by mistake. The honest answer is rename it to .zip, pull the SDLXLIFF out and work from that, because there is no clean path.
The one-directional design is deliberate. The package model assumes the project lives with the agency and travels out temporarily. It works well for a PM coordinating eight translators across four languages. It works badly for anything resembling a peer-to-peer handoff, which is why translators passing work between each other usually skip packages and exchange SDLXLIFF files directly.
One more thing about returns. Studio will happily build a return package from a partially completed file. Nothing warns the PM that only 60% of segments are confirmed. The status is visible in the project view after import, but only if somebody looks.
The handoff sequence, step by step
The round trip has six stages, and each one hides a decision the sender can get wrong.
The project manager creates a project in Studio, adds the source files, and runs preparation: conversion to SDLXLIFF, TM analysis, pre-translation if the workflow calls for it. This is where the word count and the match breakdown come from, and where pricing gets fixed.
Then the PM builds the package and assigns tasks. A package can be scoped to a single file, a language pair or a workflow step. Assign a translation task and a review task to the same package and both people will be working in the same file at different times, which is fine when the sequence is enforced and a mess when it isn't.
The translator receives the package and opens it in Studio. The project appears locally with the TM, termbase and settings attached, and from that point they work as if the project were their own. That is the whole point of the format.
When finished, they run Create Return Package, select the files and send the SDLRPX back.
The PM imports the return package. File status updates, the TM absorbs the confirmed segments if that option was set, and the project moves to its next stage.
Finally the PM generates the target files. This is the moment layout problems surface, and it's almost always too late, because the translator has invoiced and moved on. Generating a test target file before the package ever goes out catches most of it. That's the step agencies skip when they're rushing, and we'd argue it's the most useful five minutes in the sequence.
Where package handoffs break
Three failure patterns account for most of what we hear about.
Version mismatch. A package created in a recent Studio release won't open in an older one. Trados is generally backward compatible, so newer Studio reads older packages, but not forward compatible. A freelancer running a 2019 installation who receives a 2024 package gets an error that explains nothing. The fix sits on the sender's side: ask what version the translator runs before you build the package.
Wrong file returned. Translators send the SDLXLIFF instead of the SDLRPX more often than you'd think, usually because they worked in a different tool and never had a return package to create. It's recoverable. The PM can update the project manually by dropping the SDLXLIFF back into the project folder. It's also twenty minutes of fiddly work per job, and it breaks the automatic status tracking the package model exists to provide.
Missing resources. The package arrives without the termbase, or with a TM set to the wrong language variant, and the translator either works without terminology or stops to ask. Neither is good. This usually traces back to a PM building packages from a template that was set up for a different client.
There's a quieter failure too, and it costs more than the loud ones. A package that technically works but ships stale reference material: a style guide from two years ago, an outdated do-not-translate list. The translator follows it faithfully, the client's reviewer flags forty terms, and everyone blames the translator. Reference files inside a package carry an implicit authority that loose email attachments never do.
Working with a package when you don't run Trados
Not every translator owns a Studio license, and not every agency treats that as a reason to decline the job.
memoQ imports SDLPPX directly. It reads the SDLXLIFF files, the TMs and the termbases, and it can produce an SDLRPX on the way back, though how faithful that return is depends on version and on how exotic the source formatting gets. Phrase and several other tools handle SDLXLIFF but not the package wrapper, so the translator unzips manually and returns loose bilingual files. That works technically and irritates project managers, because it breaks their status tracking.
If you take the unzip route, two rules. Never touch the tags: SDLXLIFF is XML, and the inline tags carry the formatting that gets reassembled into the target DOCX, so a tool that mangles them produces a file that previews fine and fails at target generation. And confirm segments properly, because unconfirmed segments won't populate the TM on import even when the text is sitting right there.
The honest caveat is that this path is a workaround, not a workflow. If packages are a regular part of your income, the license pays for itself in avoided friction. If they turn up twice a year, the workaround is fine, and we'd rather see someone deliver clean SDLXLIFF than turn down the job. We've also written separately about adding an AI step to a Trados-based workflow without changing the tool you deliver in.
When the source arrives as a plain DOCX, XLSX or PPTX rather than a package, there's no container to unpack and the question becomes how to run the translation with terminology under control. That's the gap SnapIntel was built for: you upload the document, review and approve a glossary and prompt before translation starts, and get back the translated file along with a QA report, a quality rating and a neutral source/target XLSX you can import into Trados or memoQ afterwards.
When a package is the wrong container
Packages carry overhead: build time on the PM side, download time on the translator side, version compatibility risk, and a return step that only works in one direction.
For a 12,000-word technical manual going to one translator with a TM and a termbase behind it, that overhead buys something real. For a 400-word press release with no TM history and no terminology to speak of, it buys nothing, and a DOCX would have been fine.
Agencies default to packages for everything because it's the button they know. The cost is invisible on any single job and adds up across a month. A PM building 60 packages a month at four minutes each spends half a working day on container assembly, and none of that time touches the translation.
The other case where packages are the wrong answer: when the client's reviewer is a subject-matter expert with no CAT tool and no intention of acquiring one. Send them a package and the file comes back as a PDF with handwritten notes. A bilingual table in Excel, or a DOCX with tracked changes, gets you structured feedback you can actually re-import. If you go that way, importing the bilingual Excel back into Trados, memoQ or Phrase is usually less fragile than trying to reconstruct a package around the reviewer's edits.
Some agencies run a middle path: package for the translation stage, where TM and terminology matter, loose files for the review stage, where the reviewer's comfort matters more than TM integrity. It costs a little status tracking and saves a lot of arguing.
This doesn't apply cleanly if your TM is the deliverable. Some clients buy the updated memory as part of the job, and in that arrangement every segment has to come back through a channel that writes to the TM, which in practice means the package round trip. Decide that at quoting time rather than at delivery, because retrofitting a TM from loose bilingual files after the fact is alignment work, and alignment work is slower than it looks.
What to check before you send and before you return
Before sending, three checks take about five minutes between them.
Generate a target file from the prepared SDLXLIFF and open it. If the layout is already broken before translation, it will be broken after, and catching it now costs nothing.
Look at the package size and at what's driving it. Anything over 100 MB usually contains something nobody asked for: a full client TM, an AutoSuggest dictionary, a folder of reference PDFs.
Confirm the recipient's Studio version. That's one message.
Before returning, two checks. Confirm every segment is actually confirmed rather than merely translated. Then run the QA verification that shipped inside the package instead of your own profile, because the PM's import will run theirs, and finding the discrepancy on your machine is cheaper than finding it on theirs.
Here's the thing worth doing today. Pick one client you send packages to regularly, open the last package you built for them, and compare what's in it against what the translator actually needed. In our experience there's at least one thing in there that's dead weight and one thing missing. Fix both in the template rather than in the next package, and the fix stays fixed.