Hi Ian Teacher and ,

I just received the same error message again. This time it wasn't several files merged together, but single XML files. So, I decided to test further.

Since I have reported a strange behaviour when writing translation units to TMs, where the date format gets messed up with, and this message seems to be related to a DateTime phenomenon, I tested for this error message on two different Windows systems - same as I did for the other issue.

The result was that on a Windows system set in English with the corresponding date format, I could not reproduce the above mentioned error message when switching between files in the Editor. When I tested the same files on a second Windows system set in German with corresponding German date format, I always get the error message.

That is why I suspect these two issues are related and mean a major bug worth being addressed, in my opinion.

It is worth mentioning that this error message seems to appear only when using or having used the integrated Advanced Display Filter 2.0.

Here is the threat for the other date format issue I noticed: Wrong date format in TM system fields.

Paul, do you maybe have an idea what could be causing this? I think this issue is worth being addressed sooner rather than later.

As I mentioned in the other question I asked, which I think is related to this question here: At our company currently translation units are being wirtten into TMs with the wrong date format. This could lead to not being able to find certain TUs using filters in the future.

The error occurring when switching between files in the Editor when having a filter activated in the ADF 2.0 does not seem to be critical. But annoying it is.

I'd be glad if someone could help resolve this.

Paul, do you maybe have an idea what could be causing this? I think this issue is worth being addressed sooner rather than later.

As I mentioned in the other question I asked, which I think is related to this question here: At our company currently translation units are being wirtten into TMs with the wrong date format. This could lead to not being able to find certain TUs using filters in the future.

The error occurring when switching between files in the Editor when having a filter activated in the ADF 2.0 does not seem to be critical. But annoying it is.

I'd be glad if someone could help resolve this.

Luciano, Ian Teacher,

Probably related to this problem:

https://gateway.rws.com/csm?id=kb_article_view&sysparm_article=KB0036794

The development team are aware of it and will resolve in a future release.  Until then the locale you are using for windows seems to be the only workaround we have.

Thank you for your quick reply, Paul.

Good to know this is being taken care of.

Hi Paul. Hope you had a good start into the new year!

I have just tried to reproduce this error again with different versions of Trados Studio 2021. The error seems to habe been fixed. However, I do not understand how this could happen without me having installed any update that could have fixed it.

Is it possible that the error was fixed with a Windows Update? Otherwise it would be very strange.

Still not fixed on my installation - Win 10 Pro (all updates installed) + Studio 2021 (all updates installed). It has been annoying me for some time as when the issue occurs, I can't even close Trados properly. I have to shut it down via CTRL+ALT+Del.

Error has not been fixed for me either and have to regularly shut down Studio in task manager. I run Windows 11 on Parallels.

Karlito, Ian Teacher, you were right. I just had the error message again. Not miraculously fixed then. 

clearly not a very high priority for them

In a few years, Trados Studio has evolved from a simple CAT tool to a very complex translation machine. The developers keep adding new features instead of improving existing ones, mainly because the market is expanding at such a fast pace that major competitive products now outperform Trados in almost every aspect. The Trados code is very heavy and the amount of bugs and annoying features keeps increasing. I personally would prefer having a streamlined 64-bit Trados that loads fast and helps me do my job efficiently without crashing at every occasion rather than a Windows 95 product that has been modified to run on Windows 10.  Until that happens, we have to live with the bugs, I guess.

Karlito Ian Teacher Luciano

Did the workaround changing the language in your windows settings work for you?

https://gateway.rws.com/csm?id=kb_article_view&sysparm_article=KB0036794

Can you remember not to switch between open translations while using the Advanced Display Filter?

Or is this problem caused by something else for you?  If it does please create a new thread and provide details of when it occurs.

For reference the problem shared in the original post, as this message could be caused by other things, is our reference CRQ-23920 (just to make it easier to follow up on).  To date this work has not been prioritised over other things but it is currently assigned as a P2 High so should get some attention.  Loredana Stoia fyi.

Karlito said:

major competitive products now outperform Trados in almost every aspect.

If you can name the products and a dozen of these aspects for each one it would certainly be informative for us so I really would be interested to hear your opinion.

Karlito said:

I personally would prefer having a streamlined 64-bit Trados that loads fast and helps me do my job efficiently without crashing at every occasion rather than a Windows 95 product that has been modified to run on Windows 10.

I understand the emotion behind this statement so won't correct you technically... other than to say Win 95 support was ended in 2001 so you do the maths.  But I think we all agree we'd love to have a streamlined software that loads fast and never crashes.  64-bit is a well misunderstood comment many users make, but there is no doubt it would help handle large files.

The development team don't just keep adding new features and have been making significant changes to the underlying code in Trados Studio for some years now as we prepare to be able to support the platforms that most users will be asking for in the future.  It isn't easy, and we appreciate the patience of all of our users, but we will get there and every new release does get closer in many ways to allowing us to attain the goal of a faster and more robust solution that is capable of supporting all of our userbase into the future.  Certainly we're not afraid of feedback and do welcome it in these forums.  It can be painful to have to deal with similar complaints from other users, and from problems that go unsolved for a long period of time, but it also serves as a reminder of what we need to solve and we are committed to this.

Thanks for your lengthy reply Paul. It was not my intention to cause harm to Trados in any way or promote other companies. Trados is still an excellent program yet it seems to be the only program that is prone to crashing constantly on any PC I have (and it appears that often these problems are caused by Microsoft products - pity that Trados is so dependent on Microsoft Windows/Office). I've had this particular problem for a very very long time and I always thought that it was related to Groupshare (it isn't as you say). However, I do not wish to change my Windows settings as I use various other programs and CAT applications besides Trados and I'm afraid that changing such a setting might cause a hundred new problems in other important programs. I guess I'll wait until the bug is squashed in a future release - I'm sure it will be soon now that you know about it.