Update: I deleted the TM entry, and then it showed the new version of my translation. So it adds a duplicate when you update a row, and it shows you the older version when you get a fuzzy match. Very odd, if this is by design.

Timothy Barton

This might be elated to the use of lookahead which caches three segments ahead to make the lookup faster... especially when working with machine translation.  The downside of this approach is that even though you changed the entry you will still see the cached result when the segments are so close to each other.

Try turning off lookahead and see if this results in the same behaviour for you:

Thanks. That was the problem. Perhaps a warning message could be given when this option is activated? It's pretty dangerous if you're unaware of the behaviour. I've also been reading that you should only use it if the translation will be completed in one session. My current text is 6,000 words long, meaning I can't possibly finish in one session. Does this mean the organization will be re-charged every time I open the file? Why not limit LookAhead to the next 10 segments? That way, people don't get charged multiple times. It's nice having TM hits appear immediately, but not if, every time it does, I have to double-check that it's not a segment I've made changes to.

Timothy Barton

Timothy Barton said:

I've also been reading that you should only use it if the translation will be completed in one session.

Where did you read that?  News to me.

Timothy Barton said:

Does this mean the organization will be re-charged every time I open the file?

Charged for what?

Timothy Barton said:

Why not limit LookAhead to the next 10 segments?

It's already limited to the next three segments if we made it ten it would be slower and defeat the purpose, and it would undoubtedly be more problematic for more users.

This feature could definitely be improved... no arguments from me here.  But I don't really follow what you mean in this case.

Paul Filkin said:

I've also been reading that you should only use it if the translation will be completed in one session.

Where did you read that?  News to me.

Here: docs.sdl.com/.../lookahead-and-the-mt-quota

The warning about completing the translation in a single session made me assume the LookAhead operated on the entire document. If it only does three rows, that seems sensible, and I should always be able to detect any issues like the one I encountered. I'm therefore mystified as to why your site recommends translating the entire document in one session, as we're only ever going to get charged twice for three rows.

In any case, my organization uses its own MT engine, so is not being charged anything. I'd originally misunderstood and thought that it was the actual use of Lookahead that was being charged for, not the resulting MT.

Timothy Barton

Timothy Barton said:

Here: docs.sdl.com/.../lookahead-and-the-mt-quota

I see what you mean now... although you may have taken it slightly in the wrong way.  The advice is simply meant to ensure you don't spend time going over the same document more than once since some MT engines (if you're using MT) charge by the word, or use up free quotas, every time you enter a segment irrespective of whether it's been translated or not.

Worth noting however that there are things you can do to ensure this doesn't happen even if you are working with machine translation:

1. use the SDL MT Cloud plugin as opposed to the out of the box SDL Language Cloud
   
   
   
2. use a 3rd party MT Provider that has an option not to resend the segments:
   
   
   
3. use a 3rd party MT provider that offers a flat fee
   
   
4. turn off the option to apply MT to confirmed segments.  Not as effective as the first two since these will also apply to draft segments, but still useful:
   
   
   
5. use your own MT... which you do :-)

I'd also clarify that the way lookahead works is if you start from the top it does this:

1. segment #1: returns three segments and caches them
2. segment#2: returns one more segment as you already have the next two cached

So it basically just stays ahead of you, so it's not as bad as multiplying up the file by three.

My latest post is related to this thread, but I'm having the same issues with segments that are far apart. Here's the scenario:

• I translate a segment
• Later in the document I find a similar segment, and I'm not happy with my original translation, so I go back and change it and send it to the TM
• When I return to the second segment, I still see the result from the first time I translate it.

In this particular scenario, I know that the TM hit is correct, but I go back and change things earlier in the translation all the time, so every time I get a fuzzy match I need to check that the translation being shown is my latest version.

Others have reported the same bug: Studio 2017 won't update confirmed segments in TM (SDL Trados support) (proz.com)

(In actual fact, it is updating the confirmed segments in the TM, as can be seen if I do a concordance search, but the Translation results do not show the latest version. I guess this probably only applies where Trados already performed the TM search before the edit was made, caching the results.)