Being smart about a Studio Package…

Everyone knows, I think, that an SDL Trados Studio package (*.sdlppx) is just a zip file containing all the files that are needed to allow you to create your Studio project with all the settings your customer intended.  At least it’ll work this way if you use Studio to open the package… quite a few other translation tools these days can open a package and extract the files inside to use but not a single one can help you work with the project in the way it was originally set up.  One or two tools do a pretty good job of retaining the integrity of the bilingual files most of the time so they can normally be returned safely, others (like SmartCAT for example… based on a few tests that verified this quite easily) do a very poor job and should be used with caution.

So, add a zip to the end of the file name like this for example and you can unzip the contents to see what’s in there:

What is in here exactly?  It’s going to be different for each package as it depends how the project was originally created but this is a good example to explain what all the folders are for.  This package is only bilingual, but of course there could be many more language folders in here for a multilingual project:

• AutoSuggest Dictionaries: this folder will contain any *.bpm files that have been provided by your client.  These are only useful for Studio.
• de-DE: in this example this is the target language folder. This contains the fully segmented target language sdlxliff files, or the bilingual files.  These are the files you are actually working on.
• en-US: this folder is the source language folder.  It contains unsegmented sdlxliff files, and possibly a copy of the source files depending on how your client set the project up.  The source files might be embedded into the sdlxliff files as binary code and if this is the case Studio will be able to recreate them if you wish.
• Reports: this will contain an analysis of the work required in this project and could be the basis of what you will be paid. It’s xml but from Studio you can save this in other formats such as Excel, and you can read the analysis in a nice format.
• Termbases: this contains the filebased termbases that have been made available to you by your client. MultiTerm is infinitely flexible and can create termbases in many forms.  There isn’t another translation environment capable of using all the information you might have been provided in here.
• Tm: this could contain Main Translation memories, or Project Translation memories all indexed to support improved recall, and in the case of Studio 2017 support fragment matching and fuzzy match repair as well.  No other translation environment can use this as they all convert to TMX and import into their own format.
  • you also have all the language resource settings which are not used by other tools extracting content from an SDLTM – variable lists, abbreviation lists, segmentation rules, ordinal followers, fields & attribute values that could be required during the project but are not in the TUs yet (so they won’t be in a TMX export)
• *.sdlproj: this file stores a lot of important data that can be used by Studio for these sorts of things:
  • path to the local termbases, translation memories, autosuggest dictionaries
  • URI information for any server resources being used on this project
  • term recognition options for working with the terminology
  • term verification options, particularly for checking forbidden terms for example
  • QA verification settings for this project, and also any customised rules created for these files in particular
  • control for whether QA should be run based on custom settings before package is returned or not
  • filetype settings
  • translation memory settings and search options
  • custom export for external review settings
  • analysis bands configured for this project
  • custom batch task settings and configuration
  • URI information for any machine translation providers configured within Studio

Now, I can imagine that some people who use other tools for translating Studio packages would say none of this is important, they only require the sdlxliff files.  This may well be true for the translator.. but many people who prepare packages in Studio spend a lot of time making sure these settings are optimised to provide the best experience for the translator, to ensure the resources required for the project are being used, and to ensure there are minimal problems when they get the return package back.  Quite often I see files that have been returned to a client that at best have incorrect languages in the XLIFF, missing tags, fail QA, incorrect statuses, can’t save the target… and at worst cannot be used at all.  This is often the result of handling the bilingual files in other translation environments that state they can handle a Studio package, and the bilingual files.  The bilingual files are just XLIFF, so handling them in a different tool is of course possible… yet despite this some are not so smart about this at all.

I’d be wary of false claims.  I do know many translators who regularly work with translation environments other than Studio and they do this quite successfully.  Normally they also own a copy of Studio so they are able to make sure that the files are safely returned to their client after completing the translation in their tool of choice.  I see this the other way too, where some translators prefer to use Studio than the tools that created the bilingual files they are working with… the same rules apply and most also have a copy of the tool that created them.

The return package (*.sdlrpx) is also a zip, but this contains a lot less.  A question that comes up quite often is “How can I stop my personal Translation Memory from being sent back in the return package?”.  The answer is simple… the return package does not contain a Translation Memory at all… in fact there is no mechanism to put one in there even if you wanted to!  For my sample project above I’ll probably get one that looks like this:

The de-DE folder contains the translated sdlxliff files and your client will use these to update their Translation Memory once they are happy that the translations are all correct.  In fact these sdlxliff files will automatically replace the ones in their project when they open the return package, so it’s very important that the return package is correct and the sdlxliff files in there are not corrupt in some way.  Problems here could be a reason why your client can’t update their memories, or save the target translation.

The File Types folder… I have no idea why this is returned as it seems to be redundant.  So either this is a hangover from the past or there is some edgecase I’m not aware of that is supported by the content of this folder.  I’m actually on leave as I write this, so perhaps I’ll find out when I get back and update this post accordingly!

Package Reader

I started this article talking about unzipping a project package to see what’s in it… so perhaps also take a look at the Package Reader on the SDL AppStore.  This very useful application allows you to read the contents of a Studio package and a return package without having actually unzip it:

The main screen gives a very nice summary of the analysis, how many files, what resources are included… and can do this for each target language in the package if it’s a multilingual project.  You can even view the content of the individual files if you want to take a quick look to see who best to share the package with if you work in a team.  Very handy!

I realised I have written about packages in Studio in the past, but thought it might be useful to have a little update.  But if you’re interested in more you can find these articles here:

Working with Packages

The ATA53 Studio presentation in San Diego…

They’re a few years old now but still contain some useful information I think…