David Bowden 

This is an extremely unlikely scenario.  How did the translator manage to do this in the first place?

Whilst looking forward to learning how this was done, the resolution is probably this:

1. open the 1.2 in Studio, at least 2019 onwards I reckon although earlier versions would probably suffice
2. update the contents into a TM
3. open the 2.0 version you needed in the first place and pre-translate from your TM

But I can't help imagining that the problem is not what you think it is as I find it almost unbelievable that the translator would have converted this from 2.0 to 1.2.  Unless of course we're missing the obvious and you were sent an SDLXLIFF and not an XLIFF?  SDLXLIFF is always 1.2 even if you start with an XLIFF 2.0 (in fact any filetype you start with will become an SDLXLIFF when you translate it), and you would save the target file to get the original format back.

Paul,

Thanks for your reply - this is clearing up something for me now.

Paul said:

How did the translator manage to do this in the first place?

... That's what I thought - if you can read 2.0 why persistently produce 1.2?

But now I'm looking back at a variety of attempts at this which came from the translation agency with "1.2" metadata at the top, they are indeed sdlxliff files (apart from a couple of very strange xliff 2.0 files which were anything but when opened up). I'd not understood what I was seeing there - and evidently the translators weren't either. This was only happening with an English to Japanese translation. We had 11 other language translations of the same material which came back without issues. So you start believing weird stuff about Japanese being different and only supported in XLIFF 1.2 !!

Someone on their side figured it out in the end and we ended up with a workable xliff 2.0 so all was well in the end.

But if we hit this again we will be better armed.

Thanks!

David