Hello @Luciano 

I haven't seen this reported by anyone so far.

Is this happening in only selected system fields (created/modified on) or in all system fields?

Are the TU's generated by the same translator or by different translators, maybe based in different countries?

If you create a test project and TM- do you notice the same behaviour?

Hi Luciano,

I believe that the date format in the SDLXLIFF is right.

Regarding the date format shown by Trados, I believe it has to do with the Windows settings. What are your settings if you go to Settings > Region?

These are mine, and I've played a bit with this date format and I can confirm that Trados follows this settings.

☛ If you change the date format, you may need to restart your PC or Trados.

Hi Jesús Prieto,

Thanks a lot for your hint. This will most probably be the cause. However, I just performed a test as follows: I created a project once with Studio 2021, once with Studio 2019 on the same system with Region settings set to M/d/yyyy.

With both versions creation_date, change_date, last_used_date and insert_date are all entered with the same format: yyyy-M-d.

Then I did the same on another system with Region settings set to M.d.yyyy. Here, Studio 2019 performs as expected and writes into the TM the same format as on the other system: yyyy-M-d. Studio 2021 however writes the insert_date with format yyyy-M-d but creation_date, change_date and last_used_date with format yyyy-d-M.

To my perception this is a bug. Do you have other suggestions on how to solve this?

Hi ,

Thanks for taking the time to dig into this. As far as I can tell, the issue concerns creation_date, change_date and last_used_date.

Please find further explanations on our issue in my reply to Jesús Prieto.

Hi and Jesús Prieto,

Have you been able to find out something?

I have just tested deactivating the option to update translation unit system fields with information from the SDLXLIFF when performing an update of the main TM on the system where before the wrong date format was written to the TM. Now Studio 2021 wrote the correct date format. Unfortunatelly this way we lose the also relevant information on the users which has to be read from the SDLXLIFF.

As far as I unterstand the problem, Studio 2021 seems to have problems when reading information from the SDLXLIFF. Depending on the region settings within the system Studio is run on, Studio reads date formats inside SDLXLIFF differently. That is my conclusion so far.

Hi Luciano,

I've never seen a wrong date in Trados Studio.

Could you please share some screen-shots to prove the bug? Remember that the date is saved in the XLIFF using fixed format and shown up to the user using the date format set in Windows settings.

Hi Jesús Prieto,

I've also never seen this happen. But now I do, and it is related to Studio 2021, since we've started to notice this strange behaviour in June this year, just after we switched licenses to Studio 2021. Also, I tested the error against Studio 2019 and it does not happen there.

In my first message I already provided two screenshots. One from the sdlxliff and one from within Studio. It is not the same translation unit on both but in my opinion it should suffice to prove the bug. I am using Trados Studio in German, as almost all my colleagues do, and I am getting TM results from October 2021!

Hi ,

Any news on this? In the meantime our TMs continue to be updated with translation units with wrong dates.

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