Thank you Tomas - we did address issues with umlauts in other resources such as file and report names - so I will forward this right away to our engineering team to take a look and hopefully we can address this in the next update. BTW, this issue should not happen if the sender of the package uses CU3 to our knowledge. That could also be an option to look at for you perhaps. Thanks, Daniel

Hello Daniel, thank you for the answer.

Is CU3 the internal version 48878? With this CU we didn't have the problem with umlauts.

Regards!!

Yes - CU3 is build 55768 - so you are saying it does not occur there? This would be good news.

This is not happening with CU3. My tests were successful with the previous version but just after upgrading to version 55768 I had the same problems with the umlauts that our translators were reporting to us. The latest update has problems to manage filenames with umlauts that are included in the project packages, for example terminology has a umlaut in the name, and then when Trados decompresses the translation package to start the import, the name is changed by a different character than was registered in the project settings, so it does not find the terminology, because Trados itself has changed the name incorrectly.

Regards!

Hi Tomas,

I am sorry, I mistyped above. CU3 is identical to 55768 actually. But I was wondering if this flow works:

1. You create a project package with CU3/55768.
2. Translator also uses CU3 to open the package.

In that case there should be no problems with umlauts (so I am told by our engineering team) - i.e. if everyone is on CU3 it should not be a problem. We updated a third party library used for decompressing packages, and that actually now has better support for umlauts in file names, but that improvement causes problems with older packages. A bit of a dilemma... Anyway, maybe see if the above process works at least while we also analyse this further on our end. Definitely, translation files and report files should not cause problems. We do show a message but then the package can still be extracted. Anyway, if you have any such issues, I would recommend to log this with our support team so we can escalate this via that route as well.

Thanks, Daniel

Hi Daniel, we've tried and it's right. The problem appears when the project has been created with the previous CU and tries to open the package in a Trados with the CU3/55768. If we create and manage the translation with the CU3 installed in both points (project manager and translator) there is no problem.

Thank you very much!​

That's all very nice, but what if project packages are created in a pre-CU3 version of Studio (and I obviously cannot force the translation agency to upgrade) and my translator's version was automatically upgraded with CU3?

I thought I could use the Windows feature to uninstall upgrades, but the CU3 upgrade is not even listed (nor any other upgrade to SDL Trados Studio 2019 SR1). 

I can't believe I'm the only one in the SDL community experiencing this significant flaw in the version management process by SDL.

Harry Borsje

Is this a real problem you have encountered or is it just a supposition?  If it's a real problem then unzip the package, translate the SDLXLIFF files and send the SDLXLIFF files back instead of a return package.

Hello Paul. Yes, this is a very real problem, that I encountered - without warning - only this week for the first time. After finally figuring out where the problem came from (an error message saying "Cannot find part of the path <TMP file location>" is NOT very helpful) I'm now using the workaround you mention, but since it's quite an elaborate file/folder structure I received, I'm not sure how much trouble I'm creating for the agency when I send all files back individually instead of in a return package.

Harry Borsje

You should be able to retain the folder structure.  Just create your project based on the folders and not the individual files.