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?
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!
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.
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
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:
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
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.
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…