Start a new topic

Match repair and non-translatables

I haven't verified this yet, but my assumption is that any fuzzy match only differing in one or more non-translatables (both the original source and the new source contain non-translatables at the differing positions) will always automatically be repaired.

Right or wrong?

That's right. There is also another useful feature called Auto-propagation of non-translatable fragments. It auto-propagates the currently-translated segment to other similar segments that differ only in non-translatable fragments.

1 person likes this


What am I doing wrong here: ?

I hoped that all proper names in the second (later added) Word document would be replaced automatically in the fuzzy matches. I've added all names to the list of non-translatables (you can see by the purple colour that they are being recognised).


Please check if you have "Fuzzy match auto-correction" enabled in Edit > Preferences > Auto-assembling tab (and restart). If that does not help, submit a support ticket attaching your test in the .ctp package.


I've repeated the test. I've now glued both Word documents and verified that "Fuzzy match auto-correction" was enabled at the Edit > Preferences > Auto-assembling tab (it already was).

I'll make a package and submit a support ticket. Thank you for looking into this!


I also think that the match repair doesn't work in the scenario in the video (similar document added to an existing project). Well, you have the files now to verify :).

In Fuzzy Matches, CafeTran repairs with non-translatables the unrecognized parts as a whole (e.g. Parallex TM in the above screenshot is not corrected with Anadex TM because you don't have it in your list of non-translatables).

Not sure why CafeTran takes the space plus TM into the difference. Why's that? The TM string is invariant.

In its current implementation, CT does not treat ™ character as a single word so the search engine does not recognize it.

Login to post a comment