Client cannot open translated package

Hello,

I'm hoping someone can help with the following (I didn't see anything similar on the forum). One of my regular clients has suddenly started to experience  problems with the translated packages I return to them. This has happened for several consecutive projects. It happens as follows:

1. I receive package.

2. I open package and create project on my computer. I receive an error message that the path name is too long, so I create I shorter path.

3. I translate and complete the project. No errors are encountered.

4. Create return package and email it back to client.

The client has been kind enough to give me some details as to what they see on their end as we work together regularly. They said that the following happens:

1. They open the package and a target file is generated automatically in the project folder on their hard drive, without specifically generating one.
2. When they prepare to import the package it firstly shows up as 100% translated and appears to import without any problems. However, the project then shows up as 0% translated and when they open the bilingual file the translation isn’t there.

I've been sending them an exported .tmx, bilingual and clean file as a workaround for now, but it would be nice to have a resolution for this.

A few relevant additional side notes:
1. This had happened once around three months ago, but then never again. Two weeks ago, the motherboard on my work PC died and I was fortunate enough to not encounter problems with my Trados license by just removing the hard drive and putting it in a new computer. I don't know if this is the cause.
2. I'm running Studio 2011 on Windows 7. My client is running Studio 2014. Compatibility issue?

Thanks!

Parents Reply Children
  • Do you know if you've opened the file in the Translation View since creating the package? Opening it can also revert it back to xliff format so it might be the case that the file did not have the xliff extension at the time the return package was created.

    If you think that's a possibility, it might be worth generating another return package with the file as it is now and seeing if your client can now see import it as expected (If they've already updated their project via your workaround files then they would need to do this in a copy so as not to risk overwriting anything they've done to it since).

    If you don't think you've opened the file since generating the return package, then this is probably not the cause of the issue (it may not be the cause regardless, in which case sorry for wasting your time, but we see this issue a lot and what I've mentioned above is normally the reason for it).
  • Aleyna

    Just a small hint that may help debug what is happening here.

    You can check what is inside your return package before you send it off by using the OX app  

    Package Reader

    or simply by making a copy of your .SDLRPX file, changing the file extension to .ZIP and having a look at what's inside.

    This will allow you to check whether your return package contains what you expect it to contain, which should basically be the bilingual SDLXLIFF files.

    As Darren mentioned, you should create the return package before you generate the target or finalise, because this may lead to the return package containing only the target file and no SDLXLIFF. This problem has however been corrected, I believe in 2014 SR2, but I am not sure. So, depending on which version of Studio you use, this may still happen.

    Walter

  • Thanks very much to you both! I tried the Package Reader App, and it says that my return package contains the correct files, but I'll try your other suggestions in the future and see how they work out.