The shortcomings of Trados analysis and a simple solution to be implemented

Dear SDL community,

Once again I find myself having to waste a phenomenal amount of time doing something that should be really simple.

Last night I analysed a large .idml project against a memory. The results were as follows:

Context match: 45257

Repetitions: 11173

Cross-file repetitions: 6384

100%: 7546

95-99%: 8504

85-94%: 294

New: 7304

The work to be done is to proofread everything taken from the memory and translate the rest. The problem is that the context match and 100% match contain many thousands of repetitions where the segment only has to be proofread once. As Trados gives no indication of the number of repetitions in these segments, it is impossible to know how much time it will take and therefore impossible to cost the job.

There is a workaround, which I managed to use.

Using the Community Advanced Display Filter, I isolated the repetitions in the pretranslated segments and changed their status to "sign off rejected". Then I isolated the repetitions in the non-translated segments and set their status to "translation rejected". This finally allowed me to see the work to be done (in the word count at the bottom of the screen) and therefore cost the job: 8296 new words to translate and 30417 to proofread.

The problem with doing it this way is that to change the status on a very large number of rows takes a very long time. I have a massively powerful computer with 32 Gb RAM yet it still took 20 minutes just to select all the rows and another 20 minutes to change their status. As this operation had to be done twice, it took me an hour and twenty minutes just to count the words displayed by the filter.

This problem could be easily solved by adding functionality to the Community Advanced Display Filter so that it shows the word count when the filter is applied.

I would be quite happy to pay for this functionality. My point is that the analysis function in Trados Studio is not fit for purpose and corrective action is needed, because projects of this size are perfectly normal for many translators and they need to be able to be costed quickly.

Or can anyone see any other way of doing this? Comments please?

Thank you.

Neil

Parents Reply Children
  • It is solved on small projects by locking all reps except the first instance before running the analysis. It is not solved on huge projects because locking, changing the status or even selecting a very large number of rows takes such a very long time. It could be very easily solved by showing the word count in filtered views in the Community Advanced Display Filter or by somehow optimising the code to make the aforementioned slow operations faster.
  • Hi Neil,
    I thought a bit about the issue and I must admit I don't have the silver bullet either. But what might be a help with the tools you have right now is to use the sdlxliff toolkit Paul referred to to start out by slicing the project into "pre-translated" and "not pre-translated". Each subsequent operation would then have to deal with a much lesser number of TUs. I think much of the slow speed you experienced is due to the fact that (I guess) although TUs are filtered out, Studio still munches through them each time you perform an operation.

    I agree that adding the functionality you mentioned to the CADF would be helpful.
    Daniel