Yesterday, my partner Margherita De Togni and I gave a presentation at the 2011 Colorado Translators Association Mid-Year Conference: “Trados 2007 and SDL Trados 2009: Warts and all”. The presentation examined ten defects of Trados 2007 (“classic” Trados) to see if things had been improved in Studio 2009.
The answer, for us, is a qualified pass for Studio 2009 – we find it a better CAT tools than the old version, with some really useful improvements (such as the filter bar and the concordance search on the target text as well as on the source). Some of the most frustrating issue with the MS Word/Trados combo are no longer an issue (messed-up formatting, skipping the text in tables or text boxes), some, unfortunately, are still there (unprotected URLs presented as editable text, poor fuzzy matching algorithms).
For many, of course, the most glaring defect in Studio 2009 is the program’s inability to handle legacy bilingual Trados/MS Word (.doc) files - but there are rumors that this is going to be addressed in the next major release of the tool.
If you would like to see or download a pdf file with the slides from our presentation, please click here (or the presentation title above); for details on the URL problem, see: “Trados: beware of wrong links”; for more on the fuzzy match problems, see the following posts: “One reason I believe the sooner Trados disappears, the better...”, “Proof positive that Trados programmers should change job”, “Shouldn't Trados programmers improve their matching algorithms?”, “Yet again: Trados fuzzy match woes”, and “Yet again: Trados fuzzy match woes (Expanded)”.
Well, there's at least one huge (final) client, which expects me to modify URLs (i.e. add lang=pl_PL at the end, add /pl/ in the middle of it or do something else, depends on a specific URL). So it's not true that they should always be protected.
ReplyDeleteMaybe true about "not always protected" (one of the translators at the presentation voiced a similar concern), but I would say at least "protected by default" since it is much more frequent that URLs should be left untouched than changed to a different address during translation.
ReplyDeleteYou could also argue that it's a translator's job to know what can and cannot be touched, and that URL's need to be checked carefully. I always copy fuzzy match URL's from the source so that I don't have to look for the difference. And yes, it's certainly not unusual for my clients to ask me to adapt URL's, e.g. to make them locale-specific.
ReplyDeleteEllen,
ReplyDeleteSure it's a translator's job to know what can and cannot be touched. Still, protecting what should not be touched (or even what should not usually be touched) is a fundamental part of CAT tools. Or would you prefer a CAT tool that does not protect HTML, XML and other markup?
If every time there is a URL you copy the source to the target, you are taking an extra step that would not be necessary if the URL had been protected in the first place.
Since URLs sometimes do need to be changed (as you and jhirny correctly point out), to protect or not the URLs as placeables should be a setting - whether disabled or enabled by default is a matter of choice, and I contend that "disabled by deafault" would serve the majority of instances better.
The bilingual-format issue is going to be addressed in the next major release? Seriously? I thought we'd have passed this step in CAT-tool evolution by now. But as customers seem insistent on relying on 10-year-old technology (and software investments!), SDL backs down.
ReplyDeleteHi Thomas,
ReplyDeleteYes, that is the rumor I heard. Of course in software you never know if a feature is going to be included until you actually see it implemented.
In my opinion, SDL shot themselves in the foot when they did not include backward compatibility for .doc bilingual documents in the first release of Studio: that opened the door to people starting to think whether they wouldn't be better off with other tools. They realized it soon, but they have been in repair mode ever since, first by including 2007 together with 2009, and now (if the rumor is true) by adding backward compatibility in Studio.
If i am not wrong @jhirny , It could be true.
ReplyDelete