Sonia Martos

There should be no problem with this... at least I just tested in Trados Studio 2021 SR1 16.1.5.4270:

I corrected segment #3 in the first file and it rippled through the next four files and correctly marked the segment with tracked changes.  I don't see anything specifically related to this in the KB for this update:

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

But I think it might be worth making sure you have the latest version installed first and then test again.

Hi Paul,

Thanks for your quick answer! The thing is that what you have reproduced it's not the problem I described...

If you correct something in File 1, it does ripple to Files 2, 3 and 4. But if File 1 is correct and File 3 is not, when you confirm File 1, it auto-propagates and makes the change in File 3, but without tracking the change that has actually been done, so it goes unnoticed.

In the image below, how can I know that a change has actually been made on segment 57?

Sonia Martos said:

The thing is that what you have reproduced it's not the problem I described...

If you correct something in File 1, it does ripple to Files 2, 3 and 4. But if File 1 is correct and File 3 is not, when you confirm File 1, it auto-propagates and makes the change in File 3, but without tracking the change that has actually been done, so it goes unnoticed.

Sonia Martos

That's exactly what I tried to reproduce but as you can see this doesn't happen to me.  When I do it the change is tracked.  I am unable to reproduce your problem and that's the point.  Please update your version of Studio and see if the problem still exists.

It might also be helpful if you can show the cells that should actually be changing because as far as I can see in your screenshots the firs two segments didn't have anything to change at all because the "de" isn't in there in your "before confirming" screenshot.  So I have based my effort to reproduce on your description alone.

Hi Paul,

To reproduce it, the typo has to be manually introduced only on File 3 with the file opened for translation (as this would happen when the translator has introduced that typo during the translation step).

Then you open the files in the review step and start confirming them from File 1, segment 1. Check if any changes have been tracked.

I hope this is clearer!

Sonia Martos

I am indeed quite confused here!

Sonia Martos said:

To reproduce it, the typo has to be manually introduced only on File 3 with the file opened for translation (as this would happen when the translator has introduced that typo during the translation step).

So... if the typo is manually introduced in file 3 only can you please explain who made the change, how the file got to you, what you do from that point and what you are expecting to see.  I'm really struggling to understand how to reproduce your issue.

Probably just me :-|

Hi Paul,

I'll try to explain myself better ('cause maybe it's me!)

In this situation what happens is that there is a translator with a bunch of similar files. So they start translating File 1 and most of the segments get propagated correctly. For some reason, this translator introduces a typo only on File 3 (maybe by translating each file individually or for whatever other reason). So when I, as a reviewer, get the files, I have Files 1, 2 and 4 with one version of the sentence and File 3 with a different version of the sentence: a typo.

I don't know that at this point, so I go and open all the 4 files to start my review process with File 1. And, when I start confirming that sentence, I see some shift in the length of the File 3 string, but I don't see any tracked changes. That worries me because there has been a change, but none has been registered.

If I could send you some sample mock files ready to review, maybe you could reproduce it easily.

Sonia Martos

Brilliant... perfect explanation!  Now I see the workflow and can explain why you won't see tracked changes here.

There has been a change, but because you didn't do it, and because the translator clearly didn't use tracked changes when they did it, you won't get any change registered.  When you confirm the segment you are not confirming a change you have just made so Studio hasn't got anything to do.

One possible solution to your problem is to use your TM as it was before you had these changes made.  Then run a translate to fuzzy on the files:

This will cause Studio to stop wherever the translated segment doesn't match what's in your TM and you'll be able to see that the segment without the tracked changes was actually changed because it'll be different to what's in your TM.

Another solution, and I personally prefer this one, is to use the Post-Edit Compare application from the AppStore:

https://appstore.sdl.com/language/app/post-edit-compare/610/

This way you take a snapshot of your project whenever you like (before the translation, after the translation, after the review etc.) and you can run a comparison of any two snapshots to produce a report showing you all the changes.  Tracked changes become irrelevant and yo will always be able to see what's been changed.

I was hoping there would be a more straightforward way, a one-stop solution within the program itself. Any of the solutions would slow the workflow of those involved a lot, I'm afraid. I'm dismissing the first solution altogether because it would be "messy" for the file. As for the second one, if I send the reviewed file back without that change tracked, the translator has to compare every single change of the file exported with Post-edit compare against the sdlxliff file, just in case there's something different. It could be done with a shorter file, but with data sheets of nearly 2,000 words each grouped in batches of 6, it's just undoable.

At least now I know what to expect, but I hope this gives you an idea for a future improvement of the tool.

Thank you for  your time, Paul! I really appreciate it!!

Sonia Martos

I don’t think there is an obvious improvement to the tool here. You are opening files that have been edited by others and they didn’t track the changes. This is a problem with the process followed.

I think, if we had a feature to update sdlxliff files based on the import of an sdlxliff file then I can see some value in being able to do this with tracked changes to show the change. But I doubt this is anything the development team will address any time soon.