Tuesday, 10 May 2011

!Patched! Studio: Where is the XLIFF file in this return package?

This is a quite surprising case for project managers and translators who are starting working with Studio. As a Project Manager, you'll be said: send a project package to your translator, then he sends a return package back. Click twice on it and the translation is transfered in your project.

But sometimes, the XLIFF file is "empty", in fact you didn't get any XLIFF file! Instead of it, a file in the native format... translated! (it could be worse!). You get no error message. The native file is to be found in the project folder My documents/SDL Trados Studio/Projects/[Project Name]/[Target Language].

This happens when the translator, used the batch sequence "Finalize" or the batch task "Generate Target Translations", for example to control his translation in context.

How can I see what will be sent in my return package? (advice for the translator)

In the file view, a file which has to be translated has the sdlxliff extension (See screenshot). With a double click on it, you open it the editor and are able to translate.

After using "Finalize" or "Generate Target Translations", you will see the extension of the native format (see screenshot below, here we have a *.docx file). The file has been converted back in its native format and a double click on it will open the default viewer of this native format (here, MS Word)

If you then create a return package, the file in native format will be joined in it (which sincerely doesn't make any sens to me...).

To avoid this, you have to apply first "Revert to SDLXLIFF file" through the context menu of the file itself  to make the xliff file available again (first screenshot).

Then you can create a proper return package.

To check the translation in context, the batch task "Export file" is more appropriate. The XLIFF file stays active, and the package has to be sent only once!


  1. Hi Sebastien,

    I'm wondering why you would finalize and then create a return package? You don't need to finalise at all before creating the return package, and if you want to preview the finished files you could use the batch task "Export Files", or preview in the Editor, or just "Save target As" etc.

    Does that make sense?


    Paul Filkin

  2. Hi Paul,
    I can imagine that it makes sense for those who already finalized a project before sending a return package. I posted this because it just happened at DSC and I think the information is relevant... for those who are looking after it!


  3. Thank you, Sébastian.

    Coming from Trados 2007 I am used to clean the files (in order to update the tm) before sending clean and unclean files to the client. Finalizing with Studio 2011 followed by creating a return package creates problems since the client then won't receive unclean files. So thank you for your posting, it has learned me that I should create the return package before finalizing the files.

  4. I have recently had the same problem with Trados 2014. I always finalise my files before delivery to update the memory, then send the finalised file (native format) with the xliff file created by Trados. So when it came to creating a return package, I automatically followed the same process, which unfortunately means only the native file was included in the package.
    Thanks very much for this information. It was very useful in helping me return the package in the right format for my customer.

  5. Thank you. Very helpful. I finalize my projects to have my own work stored in my own local TM, but I keep forgetting that Studio converts the target SDLXLIFF into another format. Another problem I often have in this context: the return package contains no target translation at all, only the pre-translated file I received from the PM. I thought that finalizing the project might solve that issue, but apparently all that does is create an additional problem.

    I switched to MemoQ long ago, especially because of issues like these, so when a client insists on Studio I have often forgotten about its quirks and work-arounds. Thanks to the Internet and blogs like these the issues are quickly resolved.

  6. Working on translating xliff files? Here's a localization service https://poeditor.com that can automate the workflow.