Hi Anne-Laure FARLEY

there are a few settings that will influence this. To avoid that confirmed segments are changed (esp. without prompting you), there are a couple of settings in file->options:

It might be enough to uncheck "Auto-propagate exact matches to confirmed segments". You could tell Studio to always prompt you when autopropagating a segment, just to be sure.

Daniel

Thanks Daniel, but I do want to keep auto-propagation running (my file has many repeats). I just wonder why Studio thinks 2 segments which have different numbers in them are exact matches. There must be a setting somewhere, but I can't find it.

Hi Anne-Laure FARLEY

This is not a matter of settings. The problem is that you are adding a number in your translation which is not in the source. Studio looks at the source segments, and they only differ in the number or a measurement (20" in one case, 40" in the other). As the source segments are exactly the same (except the one number), it auto-propagates the latest confirmed translation and places the changed number into the text. The whole translated segment is propagated and the one number that differs in the source and is found in the target is replaced. I am not sure how good I can explain this, but Studio's behavior is as it should be.

If you want to have Studio perform such complex replacements, you might have to look into using the free app "TermInjector", but that takes a bit of time and love to set up.

Hope this helps.

Daniel

Hi Daniel,

I see what you mean, and I really appreciate this automatic number replacement function most of the time, but, in this case, I would like Studio not to perform them, i.e. to consider two segments with differents numbers in them as fuzzy matches instead of 100% matches. Surely, there must be a way of doing that, by deactivating the automatic number modification, no?

Thanks anyway!

Anne-Laure

PS: I've worked out a way of dealing with the problem, but it implies making modifications in the target file after the translation is finished, so it is not satisfactory!

hi Anne-Laure FARLEY

In the TM settings, turn off number and measurement recognition:

Daniel

I'm not sure this will help since - if I see correctly on the screenshots - the numbers in the sentence don't seem to be recognized as numbers... most probably due to the unusual measurement unit (')., or due to the missing space between the number and the unit (20' vs. 20 ')

And that seems to be the entire problem, IMO...

Hello Evzen, unfortunately, I've tried that already and it didn't make any difference to my problem!

Thanks anyway,

Anne-Laure

You've tried what?

I did a quick test with the sentence written into a Word file and I got the number recognized (i.e. shown with blue 'underline' in the source segment)... both with and without a space between the number and measurement, and both with en-US and en-GB source TM language (as I thought that maybe en-GB wouldn't recognize the US measurement unit).

The fact that on your screenshots the numbers are not underlined blue makes me believe that something is not quite right with your TM or setup.
Since you are the only one who knows how your TM and system is set up, you need to do the investigation on your side.

HI Evzen Polenka

Number recognition can lag behind a bit, which can be the explanation of the missing underlines:

Note bene that the measuring units for inches and feet are not recognized as measurements (at least in my test) but the numbers are still recognized. If the numbers were not recognized there would be no substitution whatsoever.

When I add additional measurements (or numbers), I get a warning or error for that, and whatever is added in the translation is just considered part of the target segment without pendant in the source section, so I get the same results as Anne-Laure FARLEY - as expected:

(The 99% for segments 5 and 6 are due to a forgotten period in the source - mea culpa.)

Auto-propagation simply won't do what you want to do here. Regex does not do maths, only pattern recognition, but you could brute-force TermInjector to fill in the values you need (by creating a table and using that as your Regex rule file for TermInjector:

Might be worth it, esp. if you can auto-generate the table or if it is not too long. The Regex rule file I used for this example looks like this:

40 cm	40 cm (0,4 m)	40 cm \([0-9]+,[0-9]+ m\)
50 cm	50 cm (0,5 m)	50 cm \([0-9]+,[0-9]+ m\)
60 cm	60 cm (0,6 m)	60 cm \([0-9]+,[0-9]+ m\)
70 cm	70 cm (0,7 m)	70 cm \([0-9]+,[0-9]+ m\)
80 cm	80 cm (0,8 m)	80 cm \([0-9]+,[0-9]+ m\)
90 cm	90 cm (0,9 m)	90 cm \([0-9]+,[0-9]+ m\)
100 cm	100 cm (1 m)	100 cm \([0-9]+,[0-9]+ m\)

A bit tedious. For what it's worth.

Daniel

HI Evzen Polenka

Number recognition can lag behind a bit, which can be the explanation of the missing underlines:

Note bene that the measuring units for inches and feet are not recognized as measurements (at least in my test) but the numbers are still recognized. If the numbers were not recognized there would be no substitution whatsoever.

When I add additional measurements (or numbers), I get a warning or error for that, and whatever is added in the translation is just considered part of the target segment without pendant in the source section, so I get the same results as Anne-Laure FARLEY - as expected:

(The 99% for segments 5 and 6 are due to a forgotten period in the source - mea culpa.)

Auto-propagation simply won't do what you want to do here. Regex does not do maths, only pattern recognition, but you could brute-force TermInjector to fill in the values you need (by creating a table and using that as your Regex rule file for TermInjector:

Might be worth it, esp. if you can auto-generate the table or if it is not too long. The Regex rule file I used for this example looks like this:

40 cm	40 cm (0,4 m)	40 cm \([0-9]+,[0-9]+ m\)
50 cm	50 cm (0,5 m)	50 cm \([0-9]+,[0-9]+ m\)
60 cm	60 cm (0,6 m)	60 cm \([0-9]+,[0-9]+ m\)
70 cm	70 cm (0,7 m)	70 cm \([0-9]+,[0-9]+ m\)
80 cm	80 cm (0,8 m)	80 cm \([0-9]+,[0-9]+ m\)
90 cm	90 cm (0,9 m)	90 cm \([0-9]+,[0-9]+ m\)
100 cm	100 cm (1 m)	100 cm \([0-9]+,[0-9]+ m\)

A bit tedious. For what it's worth.

Daniel

Thank you very much for all your work Daniel. This sounds interesting, I'll have a look into it. All I want, though, is Studio not replacing numbers automatically, but you seem to imply that this is not possible... dommage :-)

Anne-Laure