Trados Packages are a half-cure for SDL users and a headache for the rest. However, you can create Smartcat projects from them.

Let’s say, you are a project manager of a translation agency. A recurring client sends you an order. The problem is: How do you pass all the docs and resources (TMs, termbases, etc.) to the translator?

If Smartcat was your first CAT tool, you will have a hard time grasping the issue. Here, you just create a project including the client’s name. The platform enables all the client-specific resources for the project. When you assign a translator to the job, they automatically get all the data they need. Thus, they can start translating right away with zero time surplus.

Thus, they can start translating right away with zero time surplus.

But for someone using desktop CAT systems, that’s quite a challenge. Translation memories and termbases grow huge over time. Projects often consist of many docs that the client wants in many languages. Ideally, you also want to report project details such as deadline and word count in an automated fashion. Sending all these files separately (or in an simple archive) can be tedious. Besides, human errors are possible when picking and combining the files to send.

That’s where packages come “to the rescue.” Trados packages, for instance, include the following information:

• Bilingual project files

• Translation memories

• Termbases

• Word count, deadline, comments

• Other Trados-specific project settings

You can create Trados packages from existing projects in a few simple steps:

This gives you a complete unit that you can send to the translator. If the translator has Trados installed, they can open it on their computer and start working. Once they complete their work, they have to prepare a “return package” to send back to you.

Packages make life a bit simpler for project managers working in Trados. If you are one, you will want to switch to packages at some point. And then you will want all your translators to do the same. But not all translators use or want to use Trados at all. When you were sending out mere SDLXLIFFs, they had the option of importing them to another CAT tool of their choice. Now this option will be gone. You’ll have to either limit your pool of translators, or switch back to the old way.

The same holds if you are a freelancer or a company that does not want to use Trados. If you are not among those who is able or willing to spend a fortune on CAT licenses, you will have no choice but to abandon the job to someone who is.

Finally, packages themselves are just a half cure. They are essentially renamed ZIP archives that contain all project-related files. In a way, they just add another level of complexity without introducing anything radically better.

Now, you can ask, why can’t all CAT tools support Trados packages? They can already import SDLXLIFFs, so it shouldn’t be hard to make a few tweaks? Besides, as we already said, Trados packages are mere ZIP archives?

That’s true, and here’s how such an archive looks like:

First, some of the files inside, such as project description XMLs and TM tables, have no specifications. (Why they don’t is another question, and we’ll touch it briefly later on.) At Smartcat, we spent almost a hundred hours to analyze and understand their structure.

Second, let’s assume that you managed to read all the files in a package, import them into your system, and finish the translation. All this will be in vain if you can’t convert them back to a “return package” that Trados expects as an output. After all, the customer is waiting a Trados package.

Finally, even if you did create a return package, you have no guarantee that Trados will read it. So it takes really, really a lot of trial and error to test out the integration and make it work.

We go to great lengths to make any new feature fit smoothly with the existing user experience. The same holds for Trados packages. As a user you might not even notice anything unusual when you upload one. Smartcat automatically breaks down the package into components and shows the list of files and translation memories as if does for any other project:

One difference is that you cannot change the set of files in the project (obviously). The wizard also allows you to customize the default settings for individual files. For instance, you can tell Smartcat how it should segment the files:

handle for existing translations:

and treat intersecting tags and placeholders:

On the second screen, you can see and edit the deadline and comments taken from the package. You can also see (but not edit) the language pairs:

Of course, you can also configure all the other settings you are used to in Smartcat. In the end, you get a project that is hardly any different from a usual Smartcat project:

Project settings

Documents

Translation memories

Now you can work with the documents just as you would in any other Smartcat project. Once finished, you can download the project as a return package and open it in Trados:

The client will not even notice the difference. (Though of course it will be the best for everyone if you convince them not to use outdated tools at all.)