• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 22 replies
  • Answers 3 answers
  • Subscribers 434 subscribers
  • Views 6653 views
  • Users 0 members are here
Options
Related

Wrong date format in TM system fields

Luciano

We are experiencing some odd behaviour of Studio 2021 when saving translations to a TM. On dates where -considering the plain numbers only- day and month are impossible to tell apart unless you know the date format, e.g. days 1-12 in June, Studio is saving translation units with some system fields in the wrong date format. So now we have TUs for different clients in several TMs and probably all working languages that were created in the future. For the moment this does not seem to be a big deal. However, there is a reason the data is gathered. So, we cannot predict when this might become a real problem.

Is this the first time someone reports this kind of behaviour? Does someone know what the cause may be?

Thanks in advance for looking into this. Here are some screenshots, first of the SDLXLIFF and then of the TM info within Studio. Opening the SDLTM with an SQLite Browser led to the same findings.

Screenshot of SDLXLIFF file in Trados Studio showing translation units with incorrect 'created' and 'last modified' dates in the future, such as 06082021 instead of 08062021.

Screenshot of Trados Studio TM info panel displaying a translation memory entry with mismatched 'created' and 'last used' dates, indicating a potential date format error.

Generated Image Alt-Text
[edited by: Trados AI at 1:25 PM (GMT 0) on 29 Feb 2024]
emoji
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
  • 0 in reply to Luciano

    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:

    Screenshot showing Trados Studio system fields with a created on date of 01102023 and last modified on date of 03032023, indicating a possible error in date marking.

    Screenshot displaying Trados Studio system fields with a created on date of 02102023 and last modified on date of 10022023, suggesting an inconsistency in date entries.

    Screenshot of Trados Studio system fields with a created on date of 04102023 and last modified on date of 24042023, showing a discrepancy in date records.

    Screenshot illustrating Trados Studio system fields with a created on date of 05122023 and last modified on date of 24072023, highlighting a potential error in date tracking.

    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 Slight smile

    Thanks, 

    Almudena
    emoji


    Generated Image Alt-Text
    [edited by: Trados AI at 1:26 PM (GMT 0) on 29 Feb 2024]
  • 0 in reply to 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
    emoji