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!

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.

Paul said:

send the SDLXLIFF files back instead of a return package

This is often unacceptable.
If the project is not managed on the agency side manually like in stone age, the suppliers are required to deliver packages, since the postprocessing engineering is automated and there is no space for clumsy, time consuming and process-breaking manual SDLXLIFF processing just because of screwed-up update spreading like a disease :-\

I did, but the fact that I'm not able to create a formal Studio return package (I will, obviously rar the files retaining the original folder structure) may create project management problems 'downstream'. I'm just one translator in a multi-language project and, apparently unfortunately, one of the few who's working with Studio 2019.

Any idea why CU3 cannot be uninstalled from Windows 10?

Harry Borsje said:

Any idea why CU3 cannot be uninstalled from Windows 10?

Yes... it's because we stopped releasing patches and each update is in fact a full install.  So you would be wise to retain the installers for each version in the future as this is the only way to roll back.

You could also contact support and they would be able to get you a link to the earlier update so you could uninstall CU3 and reinstall the older version.

gateway.sdl.com/liveagentlicensing

You have two options:

1. Submit a case using a webform
2. Use live chat to get a licence reset

You want to use the first option and make sure that you refer to this thread so the teams can see what you have tried already and why you need to have the older update.

I think it would make sense now if we provided a link to each version in a KB... I'll discuss with the support team.

Evzen Polenka said:

This is often unacceptable.
If the project is not managed on the agency side manually like in stone age, the suppliers are required to deliver packages, since the postprocessing engineering is automated

Understood Evzen.  I was only suggesting a workaround that would need to be agreed with the agency.

Paul said:

You could also contact support and they would be able to get you a link to the earlier update

In fact, the Release notes article contains a link to FTP site where one can download all installers/updaters for Studio 2017 and Studio 2019... and Studio 2015... and MultiTerm 2019... and MultiTerm 2017... ;-)