Hello Paul,

I am tagging you because I have now installed SR2 with CU9 and the problem mentioned above seems to keep happening.

During my recent tests I noticed that the error happens only when I perform a TM update. If I confirm the segment by pressing Ctrl + Enter, the date format of the translation unit is correctly saved into the TM.

However, when performing a TM update, translation units are now saved as if they were translated on June 1st 2022 (today is January 6th).

I thought this might be related to the problem mentioned in this KB article https://gateway.rws.com/csm?id=kb_article_view&sysparm_article=KB0036794. But misteriously I don't have that problem any more.

I would appreciate if someone at RWS could look into this.

Luciano J. Silva

I'm tagging someone who might be able to look at this - Adrian Maniu

There are two users for Adrian Maniu. Maybe you tagged the wrong one, since there has been no reaction. Adrian Maniu/Adrian Maniu, do you think you could help with this issue?

Hello,

This is a defect in Studio logged as CRQ-25970. Currently the development team is still looking into this and we do not have a fix date confirmed.

Thank you, Adrian Maniu. Good to know it is on your to-do-list.

Hi Adrian Maniu ,

I have read the following in the infos of the latest CU for Trados Studio 2021 (CU12):

The date and time property of TM units is now consistently being updated across date and time formats, regardless of the method of creation or update. (CRQ-29503)

Is this related to the bug I found, which is discussed in this thread and logged as CRQ-25970? Is CRQ-25970 fixed?

Hello, 

Both issues are the same, but they have been implemented in different versions: CRQ-29503 was addressed for Trados Studio 2021 CU11 and CRQ-25970 for Trados 2022.

Hi Adrian Maniu , Paul ,

After having updated Trados Studio 2021 tu CU12 for all our users we have come to realize that the issue reported above still persists. Now, however, it is only the "Created on" system field that changes the date format. Units that I create today on a German Windows system are saved to the TM with creation date August 9th. Regardless of whether my Trados Studio client was set to German or English. The TM I used was a GroupShare TM.

Hi Luciano,

Same problem here. The only solution I was given is to update to Trados 2022 :(

See (11) Crazy system fields in Translation Memory - 2. Trados Studio - Trados Studio - RWS Community.

Hi Almudena Ballester ,

It is good to hear, we are not the only ones with this problem. Even though I would't wish it on anyone.

So, judging from what you wrote in the other Community post, you are also having this issue in Trados 2022? Or did you mean that the datetime remains turned around? The latter would be the only logical thing to happen, since the datetime is written into the SDLTM file. The only way to "repair" this, I guess, would be to create a TMX export, identify the wrong time stamps and correct them in a text editor. Of course, this could mean a huge effort.

So, did you test if Trados 2022 writes the correct datetimes into the TMs?

Hi Luciano,

In the tests I have done with the 2022 version, yes: when creating new TUs, the date fields are apparently well marked.

But, a huge problem remains with translation memories created with 2021. As you can see in my other post: the datetime is marked wrong in the tmx and remains wrong, yes turned around, fixed, unchangeable. What a exasperating failure!

How can I possibly identify those wrong marked TUs? Do I compare creationdate and changedate for any of them and make some deductive logic (please IA help me out) to change it correctly? 

Here you have, just for fun, some other wrong marks:

I don't even know any more which of the fields is marked wrong and which OK.

Well. I don't think I can go over hundreds of TUs manually. If you have any ideas... maybe we can help each other with this

Thanks, 

Almudena

Almudena Ballester ,

Good to know Trados 2022 at least does not create TUs with wrong datetime.

I don't think there is any easy way to correct those units with wrong creation date. The only way would be to write a script of some sort to parse the TMX and make changes according to some pattern you may recognize in your dates. For instance, All datetimes that are in the future are 100% wrong. For those you could switch day and month without any doubts.

For other units you could compare change date and creation date. If creation date greater (later) than change date, then it's highly likely that the creation date is wrong. However, I would have to think here if there may be any situations where Trados would create a translation unit from scratch (new creation date) with a change date that lies in the past.

Probably there is no solution where the benefits outweigh the costs.

Good luck and thanks for sharing your thoughts,

Luciano

Almudena Ballester ,

Good to know Trados 2022 at least does not create TUs with wrong datetime.

I don't think there is any easy way to correct those units with wrong creation date. The only way would be to write a script of some sort to parse the TMX and make changes according to some pattern you may recognize in your dates. For instance, All datetimes that are in the future are 100% wrong. For those you could switch day and month without any doubts.

For other units you could compare change date and creation date. If creation date greater (later) than change date, then it's highly likely that the creation date is wrong. However, I would have to think here if there may be any situations where Trados would create a translation unit from scratch (new creation date) with a change date that lies in the past.

Probably there is no solution where the benefits outweigh the costs.

Good luck and thanks for sharing your thoughts,

Luciano