Hayley

That's a good question... I think the closest you'll get to this is to use the "Export unknown segments" feature where you will be given an SDLXLIFF file containing all the segments that did not have a match in your TM:

This won't only reflect the internal fuzzies because it will also include things that may not provide an internal fuzzy at all, but it might be the answer to what you are trying to get at and that sounds as though you want to handle these segments first to improve a subsequent pre-translation of your projects?

Just a thought... and this is available in 2017 too.

Hi Paul. Thanks for the quick reply. I'm actually trying to do the opposite of what you suggest though: I want to leave translating the internal fuzzies until right at the end of the project, when everything else is translated and proofread, the aim being to save time because I wouldn't be proofreading (and potentially correcting) a large number of very similar segments.  Does that make sense? Somebody suggested something similar in the ideas group (here), but the post is from over a year ago, hence me asking here. Hayley

Hi Hayley

In fact I'm wondering why this would be a better way of working?  Surely it makes more sense to tackle them first so you are reviewing the entire file in context at the end since you'll have more untranslated material handled consistently before you start on the rest. 

Anyway... in this case I'm afraid you're out of luck because I don't think there isn't a way to identify them in the files in this way.  Only in the analysis to assess the effort.

Hi Paul. Ok, thanks for the reply. I guess we'll have to agree to disagree about the order of handling internal fuzzies. I think both methods could be suited to different files/contexts, but it would be nice to have the option. Another related comment I saw online (I think on Proz) was that given that some agencies apply discounts on internal fuzzies as well as TM fuzzies, there should be a way for translators to see what those internal fuzzies are, rather than just how many there are. Is it worth me adding the idea to the ideas group, or is the post from 1+ year ago still being considered?
Hayley

Hi Paul,

I have a question which might be similar to the one posted by Hayley.

I would like to ensure similar segments are translated in similar ways among several sdlxliff files.

Is there a way to find fuzzy matches based on source segments of all the files included in a project, rather than based on Translation Memory segment match?

Or have you got perhaps any suggestion on how to perform such a check?

(Translation is already completed, I would like to perform a final check on all project files)

That is an easy one

Actually, all you needed are posted already somewhere in this community's AutoHotkey section.

Just search title under... "extract" and/or "Fuzzy" something and compile it properly.

For instance,

"extract" sdxlliffs whatever you wanted

and

score it/them with "Fuzzy" code..

right ? too easy

Good Luck to you

This one could help a little bit, though it lacks fuzzy score..

To check Multiple sdlxliffs - inconsistencies
community.rws.com/.../to-check-multiple-sdlxliffs---inconsistencies

Kelly Edward,

that's interesting, thank you for that hint!

Davide

Hi Paul,

Picking up the scent of this old thread.

It is superb that Trados allows you to filter for "first occurrences" and " to "exclude first occurrences" for 100% repetitions. It is very, very useful when splitting up a project among multiple translators to avoid divergent translations when you can lock "exclude first occurrences" segments and have the editor fill them in automatically based on the edited first occurrence segment.

It would be great if you could also do this with "fuzzy parent (i.e. first occurrence) segments" and "fuzzy child ("exclude fuzzy parent").  Again, this would increase consistency when multiple translators work on the files in a project.

It would also be very nice to be able to lock these "fuzzy child" segments as empty when performing MT to ensure that fuzzy segments are populated by human-reviewed segments, ideally using MT to "patch" fuzzies rather than to translate them from scratch.

Your thoughts?

Best regards,

Tom Fennell