Sébastien Desautel

Have you tried installing this:

https://appstore.sdl.com/language/app/worldserver-compatibility-pack-for-sdl-trados-studio/1102/

It puts the filetype back.

Hello Paul,

Unfortunately, there is still a problem for us: the file type is not available in the file type list, so we can't prepare xlf files with it, that we receive without a wsxz package. Do I miss something? Is there a way to see the file type?

Sébastien Desautel

Could be my bad here... but can you share a screenshot of wat you see in the older version?  I checked back to 2017 and don't have one in any of them.

It certainly comes from even older templates but it was still available. In Trados 2021, the file type is still in the sdlproj, but it is set as "hidden" automatically. So no chance to see it in the file type list

Here a screenshot from 2017 (we haven't used 2019 in production)

Sébastien Desautel

I'm wondering if you brought this through from 2015?  I can find it in Trados Studio 2015 but not in any of the later versions and I have 2017, 2019 and 2021 installed.

However it got there, we don't support it now, at least not as a separate filetype.  This is where it was my bad... looks like the support is inherent in the WS package handler and not as a separate filetype anymore.  Patrik Mazanek can probably explain the why's and wherefores of that.

What happens if you prepare the package in WS instead of taking the XLF files themselves?  Presumably you can then create the single project you're after as a package?

Yes, I also think it comes from 2015 projects and/or templates. 

It's not a big issue. We will use the xliff file type to prepare the files in a first step. It seems to generate the same output as the wsxliff when we choose the right options. I will check later if I can write a file type plugin to take into account the target language and only prepare each file for the relevant language pair (as actually expected) and we still have an open discussion with the client to get sdlxliff instead of xlf. wsxz packages would be another alternative, you're right. Thanks for your feedback.

Sébastien