Hi Balázs,

Do you mean return package?

Not really, this creates a Studio Return Package. I am looking for one that can be uploaded to SDL WorldServer.

This method produces a return package that for some reason cannot be imported to WorldServer, it produces this error message: "The import attempt failed because the selected file "Testpackage-2016516-10h59m0s.sdlrpx" does not have a recognizable extension by WorldServer, or metadata file is missing from the contents of the selected file if the file is a zip archive."

What is needed is an *.wsxz package created from this *.sdlrpx. The wsxz is essentially a stripped down xliff in a zip file that can be imported by the WorldServer.

Hi Balázs,

Yes, the documentation is very poor, so there are a lot of undocumented features.
However, the Sdl.TranslationStudio.Packaging.Convertors.WorldServer.dll is not marked for public use, so if you try to use it you will get an error when Trados loads your plug-in.

You may be able to use a workaround though like Eric Bishop mentions, i.e. zip the files yourself.

You can generate the sdlxliff file to the xliff and then zip it.

To generate the xliff data, use the RunAutomaticTask function:

Example:

project.RunAutomaticTask(projectFileIds, AutomaticTaskTemplateIds.ExportFiles);

 or

project.RunAutomaticTask(projectFileIds, AutomaticTaskTemplateIds.GenerateTargetTranslations);

Hi Jesse,
Thanks for the reply. Well, the sdlxliff generation is exposed easily with these simple lines of code:

            Guid[] files = new Guid[EditorController.ActiveDocument.Files.Count()];
            for (int i = 0; i < files.Length; i++)
            {
                files[ i ] = EditorController.ActiveDocument.Files.ElementAt(i).Id;
            }

            FilesController.CurrentProject.CreateReturnPackage(files, @"d:\test", "test");

 
This is a ZIP file, so you can then access the current sdlxliff in the target folder. Only this xliff is incompatible with WS.
When you create a return package with Studio, it puts the sdlrpx file through a conversion and outputs a wsxz file, which also has an xlf inside, but it is it the WS xliff format that is understood by the WS and can be imported.

So there is a converter and of course I could write another one, but I hope I can access the one someway through the exposed APIs.

Hi Jesse,
Thanks for the reply. Well, the sdlxliff generation is exposed easily with these simple lines of code:

            Guid[] files = new Guid[EditorController.ActiveDocument.Files.Count()];
            for (int i = 0; i < files.Length; i++)
            {
                files[ i ] = EditorController.ActiveDocument.Files.ElementAt(i).Id;
            }

            FilesController.CurrentProject.CreateReturnPackage(files, @"d:\test", "test");

 
This is a ZIP file, so you can then access the current sdlxliff in the target folder. Only this xliff is incompatible with WS.
When you create a return package with Studio, it puts the sdlrpx file through a conversion and outputs a wsxz file, which also has an xlf inside, but it is it the WS xliff format that is understood by the WS and can be imported.

So there is a converter and of course I could write another one, but I hope I can access the one someway through the exposed APIs.