CafeTran

Here's my example:

The time frame for the expected deliverables for<tag 1>Poland, the Czech Republic and Slovakia<tag 2>is as follows:

is propagated as:

The time frame for the expected deliverables for<tag 1> Poland, the Czech Republic and Slovaki<tag 2>a is as follows:

The tags are for bold formatting.

Note also that in the source text, there are no spaces on either side of the tags, even though there is are spaces in the original text. (And I have consequently excluded spaces in the target.)

Cheers

Jeremy

Yes, this is well-known, over here. What file format are you translating? SDL by any chance? 

I quickly remove all tags with one keyboard shortcut and very quickly re-insert them. For me this is only a small disadvantage of a great system for tag handling: only the positions are stored in the TM, the TM is not polluted by any formatting. This has the big advantage that I can F/R the TM without any formatting being in the way. And like I wrote (here or elsewhere): I'm constantly improving my old translations (in the TM).

It's a Word doc (docx), though maybe a slightly kooky one. But my problem was with auto-propagation, rather than using matches from the TM.

 

You are absolutely right! It's from that action (AP) that I recognise the behaviour. Perhaps a tiny difference is present in the two sources? A small formatting difference? An extra space?

Thing is, of course that CafeTran considers that as being identical, yet, obviously they aren't: so CafeTran starts counting from position 0 upwards and places the tag at the wrong position (too soon).

>Note also that in the source text, there are no spaces on either side of the tags, even though there is are spaces in the original text. (And I have consequently excluded spaces in the target.)

Yes, CafeTran sometimes glues words together, by taking the space with formatting into the tag.

Note that only the underline formatting is autocorrected nicely in Word, that doesn't wonder, since this would be unacceptable. For bold and italics this behaviour (automatically excluding the trailing space) isn't implemented. So, what looks identical at first sight:

The time frame for the expected deliverables for<tag 1>Poland, the Czech Republic and Slovakia<tag 2>is as follows:

The time frame for the expected deliverables for<tag 1> Poland, the Czech Republic and Slovaki<tag 2>a is as follows:

Can well be derived from:

The time frame for the expected deliverables for<tag 1>Poland, the Czech Republic and Slovakia<space_tag 2>is as follows:

The time frame for the expected deliverables for<tag 1> Poland, the Czech Republic and Slovaki<tag 2_space>a is as follows:

It's possible to run a clean up macro to avoid this. But is it really worth the effort? I once wrote such a macro (Hans van den Broek always was a big fan of my macros, he always encouraged me!!!) that converted the formatting to HTML codes in the word document, and then ran a couple of F/R actions to get all spaces before closing tags at the correct places and to always get the order BIU.

So far, so good. But of course a variation of the source document was created that way, which can have disadvantages.