What’s in SDL Trados Project/Return Packages (sdlppx/sdlrpx)?

A few weeks ago, I was asked by a potential client if I had the “Professional” flavour of SDL Trados Studio. I declined, mentioning that I was going to update from Studio Freelance 2011 to Studio Freelance 2014 until the end of September (done!). SDL currently has one of its rebate “spasms”, so I decided that ~200 euros were okay to invest after having used Studio 2011 since, wait for it, … 2011! As far as I can tell, the “Professional” variant only adds the ability to run on several machines in one network domain, to share TMs over said network, and – big deal – to create SDL Trados Project Packages (sdlppx). But is that worth a twentyfold increase in my upgrade investment?

For the current case, what the client really asked me was if I could act as a translation bureau, subcontracting other translators as needed for high volumes. My answer was: “Yes, I can share work with some colleagues I know. Fortunately, that is totally independent from owning a Trados Pro license, so don’t worry.”

Huh? Wouldn’t a proper SDL Trados workflow be to create a project, to export that project into several Project Packages (usually one per language combination, each for translation and for review), to send it to the subcontractors, to receive their Return Packages and merge them back into the local project? Well, yes, probably.

In this case though, everything revolved around 1 source and 1 target language, no multi-lingual nightmare. The client only wanted to include the TMs and Termbases into the deal to be able to consistently work with several translators for high workloads. With a minimum of fiddling, this can be done without Trados Pro – even to the point at which I do not need to send my supposed subcontractors anything SDL-specific. Some of my colleagues prefer OmegaT, memoQ, Wordfast or still other Translation Environments. Why would I force them to use Trados if I know they do good work with their own tool?

1. Unwrapping the package

The question that went around in my head, then, was: “What is inside these packages, actually?” Without reading up on anything, I supposed that the Packages would be like Mozilla XPI packages, that is, renamed ZIP files with some descriptive XML and the necessary files (translatable files, reference files, TMs, TBs) inside. So I just told 7zip to unzip a project file and a return file I found on the ‘net (important notice). Bingo!

The SDLPPX content is a folder structure like a regular local Trados project folder.

Do any Trados users recognise this? Right. It is the usual local Trados project folder structure, with the addition of one “File Types” and one “Termbases” folder. This doesn’t come as a surprise, as file filters and termbases usually are stored centrally in the Trados program folder and the relevant $user/SDL/MultiTerm/ folders to be available for all local projects.

Now, could a translator without Trados Professional just copy the relevant file types and termbases into the current project folder, zip it, rename it to .sdlppx and send it out? Most probably not. The next step, then, was to have a look at how the Project Package’s SDL Project File (.sdlproj) differed from regular Project Files. Did anyone expect something else than XML inside? No? Good, because it is.

2. Examining the descriptive XML (.sdlproj)

The first thing that springs to attention is the slightly different file name: The project name, as it would appear in a local project, is “Censored” (guilty of changing that one), but the Package file name has a time stamp appended to it.

Inside, both begin with the mandatory XML declaration, but the XML root element is already different: <Project [attributes]> vs. <PackageProject [attributes]>, where the PackageProject has the additional attributes PackageCreatedAt="timestamp", PackageCreatedBy="username", Comment="some comment", PackageGuid="unique ID" and PackageType="(ProjectPackage|ReturnPackage)". So, what distinguishes SDLPPX from SDLRPX files is one small switch.

Thereafter, we have the regular LanguageDirection block defining target and source language(s), which can also contain links to AutoSuggestDictionaries. In this block, two nodes were present in my local files which I missed in the Package file: AnalysisStatistics with TM match statistics and the CascadeItem block, which defines Translation Memory paths in local projects.

The next block is TermbaseConfiguration. The main difference between regular projects and project packages is that local paths are absolute paths like C:\Users\me\SDL\etc\termbase.sdltb and package paths are relative paths like Termbases\termbase.sdltb. I bet I am not the only translator who has tried to move a local project onto a secondary PC and then needed to manually adapt the TM/TB paths in the SDLproj file afterwards. How I wish regular projects could also work with relative paths or variables like this: %LocalTermbaseDirectory%\termbase.sdltb!

The next block, SettingsBundles, holds Project settings like the options chosen for QA, TMs, TBs, FileType options and general project options like default File Export paths. I didn’t notice anything unusual here.

Then came the blocks InitialTaskTemplate which holds the default actions for newly added files (empty for package projects), ManualTaskTemplates which holds the action to take by the package recipient (translate or review, empty for local projects), AnalysisBands which holds the TM match values for the analysis roster, Users which holds user info including e-mail for all people who have worked on (opened?) the project, GeneralProjectInfo with project name, started and completed dates, etc.

There is one solitary SourceLanguage tag before a list of ProjectFiles is opened up, each with its own match analysis block. The following block is Tasks, containing a list of AutomaticTasks and ManualTasks that have been carried out on the project, each with their own timestamp and everything.

The local file ends with a PackageOperations block (empty in my project files because I didn’t create, import, export or work on project files yet), whereas the package file ends with a PackageTasks node below the Tasks node. Inside sits a TaskRef node which references the GUID of a task in the Tasks block. So this is the package’s way of telling the package recipient which of the completed/planned tasks in the Tasks list he should carry out.

3. Conclusion

That’s about it. Some small changes in the project file and packaged file types and termbases. One could possibly generate a project/return package from a normal project folder with a not-too-complicated script. However, it will be up to you to do something with those insights: Since it currently doesn’t look as if I will have to generate SDL Project Packages and since I own a Trados Freelance to receive and work with them, I won’t put more time into it at this point. But I think it is good to know that a several thousand dollars heavy upgrade might not be that necessary in certain situations…

Christopher Köbel

IT / IT-Marketing / Tech in DE / FR / EN defrent.de | XING Profil

Veröffentlicht in English Articles, Translation Industry Getagged mit: ,
2 Kommentare zu “What’s in SDL Trados Project/Return Packages (sdlppx/sdlrpx)?
  1. Una D sagt:

    Hi Christopher,
    Thanks for the post, I was wondering the same thing too – what information exactly is contained in the return package I send to the agency? For example does it give them access to the TM I use for the translation? Or more specifically, when you mention ‘automatic tasks’ and ‘manual tasks’, do you know what kind of things come under these categories? I would be really interested to know what exactly translation agencies are looking for when they open a return package!

    • Hello Una,

      glad you liked the peek inside. To be clear: One or more project translation memories will be part of the package you receive and will be sent back to the agency, including any new segments. I can not tell at the moment if it is possible to add your own local TMs to a “packed” project during translation or if such an added TM would also be included in the return package (my best guess: if you remove it prior to generating the return package, then it should not be included) – but the segments you translated will of course be part of the return package’s own TM.

      As for “automatic” or “manual” tasks, these are the steps that have been carried out for this package, e.g. preparation of files, generation of project TMs, pseudo or MT-pre-translations (all automatic) or human translation or review tasks (manual).


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.