Hello Mariana Rios Grijalva

Thank you for your screen print. It made me laugh!

Just to clarify:

• All new segments are being saved with this incorrect date stamp?
• What about other projects and their TM's?
• Is the TM in question being shard by others?

Here are some troubleshooting questions:

• Is this a file based or a sever based TM?
• Where are the TM's stored?

Reason I ask these questions is because I have 2 thoughts:

• Date stamp on your machine or where TM's are saved to, could be wrong.
• Unintended but intended meaning:
  • It is possible this meta data was protected as part of a TM import / update
  • Or otherwise done accidently as part of going maintenance, given the meta data fields are editable. 

Looking foward to your clarifications

Lydia

Hi Lydia!

Well, we work with groupshare and that is where the TM is stored, it is a server owned by the company. The projects are stored in the server as well. And we noticed this 1899 date in a couple of segments from two different projects, the other segments from the same projects are just fine. So it's weird...

This really didn't cause any serious problem as of right now, but I thought it was weird, and I wonder if it can cause future problems, let's say when doing TM maintenance and keeping just the "most recent" version of segments, these ones from 1899 I guess will be relegated.

Thank you!

Hi Mariana Rios Grijalva

I did some digging and I can confirm the following:

From what know: this happens when the sdlxliff in question that was open in Studio is missing those fields altogether. Segments that were pre-translated with Machine Translation and get confirmed in the TM - are one way to get to this situation. Studio/GroupShare takes these default values instead of taking the current date and time and the current user.
This does not happen with file-based TMs, just with GroupShare TMs.

There is no workaround to this, as the incorrect date and the other 2 system fields are in the database like that.

The good news is:  SDL Dev was aware of this issue and it will be fixed in Studio 2021 SR1 CU4.

Please ensure you and your colleagues prioritise this upgrade when it is released in the very near future.

I hope this gives you peace of mind moving forward 

Lydia 

Hi Mariana Rios Grijalva

I did some digging and I can confirm the following:

From what know: this happens when the sdlxliff in question that was open in Studio is missing those fields altogether. Segments that were pre-translated with Machine Translation and get confirmed in the TM - are one way to get to this situation. Studio/GroupShare takes these default values instead of taking the current date and time and the current user.
This does not happen with file-based TMs, just with GroupShare TMs.

There is no workaround to this, as the incorrect date and the other 2 system fields are in the database like that.

The good news is:  SDL Dev was aware of this issue and it will be fixed in Studio 2021 SR1 CU4.

Please ensure you and your colleagues prioritise this upgrade when it is released in the very near future.

I hope this gives you peace of mind moving forward 

Lydia 

Hi Lydia!

Thank you so much for the research and prompt response. We will keep an eye on the next update