Joanne Maddocks

This is because the packages were created by an older version of Studio with an older version of the filetype.  It won't prevent you working on the file and returning the package but you may not be able to save a target file.

Is there any official SDL statement to situations like this, where

• translators are provided with a package created by some old Studio version
• i.e. packages containing old, outdated and unsupported file type definitions
• i.e. making the translators unable to deliver what they are asked for by the client (i.e. the target files, not SDLXLIFFs)
• where neither the client, nor the translator actually understand the technical side of the problem, because both are industry newbies and plainly clueless
• but because the client has the power ("I'm giving you the job and you either WILL provide me back what I want, or you won't get any more jobs from me"), everything is of course the translator's fault

This is very common situation in the industry - and the silent majority from this forum would confirm that, if it wouldn't be the SILENT majority - so it would be fair from SDL to give these poor translators something official to defend themselves and prove that the problem is not caused by them.

One would expect that some official statement would exists when SDL decided to break the backward compatibility so heavily.

Or, did SDL really officially naively believe that unifying Studio versions across the complete supplying chain is something what will just magically happen by itself, or even could be forced/driven by the poor translators?!

I completely agree Evzen. This is the situation I am currently in. The client sends me the package but expects the target file back. And as Paul points out I cannot produce that! 

Or there should be some fix to allow us to work with older file types in newer versions - surely?? 

You might be lucky enough and your client might be okay with delivering the SDLXLIFF if you provide convincing explanation of the situation.

But majority of the twenty-something newbie translators - and generally the majority of those not computer savvy ones - won't be able to explain the root problem.
And that's why I believe that SDL should have some materials ready for these people.

Joanne Maddocks said:

Or there should be some fix to allow us to work with older file types in newer versions - surely?? 

Well... if you look at the latest versions of Studio 2015, 2017 and 2019 they all use version 2 of this filetype.  How far back should we maintain this support?  You can translate the file and return the package, which is the sensible workflow anyway.

If your customer wants to use a version of the software that is no longer supported at all, and they want you to provide the target file too then they should simply send you the source file and let you do the entire job.

It's unfortunately notoriously known that "latest versions" (which often means "several CUs back"!) are flawed by various nasty bugs, causing rather serious productivity issues.

That's why many agencies stay even for years at versions which simply work for them.
Businesses DO NOT WANT to "play with new versions", they want to do their job in the first place.
They don't have reasons to hurry up and download every new "experiment" SDL puts out...

Regarding the "how far back should we..." - well, you don't have to... just provide some conversion tool for 'upgrading' the SDLXLIFFs created with the older file type to the 'newer format'... and that's it.

That's all just normal software maintenance cycle... every sane software architect must be aware of such consequences, especially when considering the important fact that it's not software for "own use" only, but software which is used by multiple parties in the supply chain, where none of the parties has any control over the software versions used by the other parties.

Evzen Polenka said:

provide some conversion tool for 'upgrading' the SDLXLIFFs created with the older file type to the 'newer format'

I totally agree.

Paul said:

If your customer wants to use a version of the software that is no longer supported at all, and they want you to provide the target file too then they should simply send you the source file and let you do the entire job.

It's rather unfair to expect this of translators. We have no control over what version customers are using. And, often, if we don't send customers exactly what they ask for, they will simply find another translator who will.

I guess I just have to hope that won't happen in this instance! 

Thanks for the replies.

Joanne Maddocks said:

It's rather unfair to expect this of translators. We have no control over what version customers are using. And, often, if we don't send customers exactly what they ask for, they will simply find another translator who will.

I agree Joanne... it's not fair at all.  Normally translators complain that the packages they have received have not been prepared properly and they would love to be able to manage this themselves so they can get the filetype preparation correct, segmentation correct etc.

It seems to me that if you have a customer who wants you to do the whole workflow from start to finish except for the preparation then the unfairness here is not anything we are imposing.  That customer is potentially giving you a hospital pass and expecting you to run with it.  That's not fair.

Evzen Polenka said:

Regarding the "how far back should we..." - well, you don't have to... just provide some conversion tool for 'upgrading' the SDLXLIFFs created with the older file type to the 'newer format'... and that's it.

This is not possible Evzen... you should know that.  You would need to get back to the original source and recreate it.  If you think this could be done another way, and avoid the potential for data loss, I'm all ears!