|
|||||
The case for and against direct update of TM’s by translatorsI was recently talking to a strategic sourcing manager who had been pitched on the idea of direct TM update by a vendor. The manager wanted to gauge my reaction and wondered whether this was something they should implement. It isn’t a new idea of course, but is one that I have always dismissed out of hand. This time I decided to should work through the pros and cons. Technically this isn’t all that hard. All the major vendors have some form of portal, and the significant players integrate that into their production back-office. Certainly the enterprise systems like SDL’s TMS and Worldserver can technically achieve this and I am sure many of the individual vendor systems can too. But as far as I know only one vendor touts this as a realistic practice. The case for direct update is pretty simple:
The case against has three main points
The Plan The idea is that you get all the translators working in an online workbench that automatically updates a central TM each time a translator translates a segment or, more conservatively, hits the save button. Since the TM is live and online it can immediately propagate that result out to all the other translators resulting in an increased TM match for the project. The main argument for direct update is cost and time savings The main argument given proponents of this method is that by having translators working directly in an online environment where completed segments are updated is that these segments can then be propagated through the system provided at least partial matches to other segments. The thinking is that this method will introduce efficiencies and systematically reduce costs by a up to two or three percent. The first argument against direct update of TMs is that it is impractical to implement. The first argument against direct update is that it isn’t in line with the way translators actually work and is in practice impossible. For the most part translators work offline using their desktop workbenches (e.g. Trados, Déjà vu) which are specifically designed as environments for translators and containing all kinds of features that make the translator’s job easier and increase productivity. I find it highly unlikely that even one of the larger vendors would have enough leverage to force all their translators to work exclusively online. The second argument against direct update is that the savings aren’t there. Even hypothetically, the only people that could be doing this are the larger vendors – perhaps the top 10 translation companies. All these vendors will already be checking for segment repetitions which are a feature of most translation workbenches anyway. Given that, for savings to be present they would realistically have to exist within matching segments in concurrent projects without much existing TM leverage, that weren’t identified as repetitions in the first place and that are being translated by different linguists. It would seem that the number of segments meeting these criteria would be very low even in large project or with customers with many concurrent projects. The third argument against direct update is that it introduces the risk of pre-QA translations being propagated. Translators are only human and errors are introduced by human translators every day… thats why we have Quality Assurance processes in the first place! Auto-propagating translations pre-QA carries a tremendous risk. Conclusions On the surface, the logic seems sound and these days we can all do with shaving a few percent from the localization budget. What I have never seen is valid metrics that show the method actually resulting in real savings or any quantification of when the benefits outweigh the risk. I met an LPM at a trade show recently who told a horror story where their vendor had transposed microgram to milligram in a dosage reference. What would have happened if that change had been auto-propagated into segments in concurrent projects? Best-practice in the industry is to refrain from TM update until after linguistic QA, and if possible until after client review. Second-best practice is to put translated segments into a scratch-TM with penalties and review – but this only works in industries where you are sure the cost-benefits outweigh the risk. I would like to hear about if this has worked in practice though… perhaps there are good examples and case studies out there that prove me wrong. 1 comment to The case for and against direct update of TM’s by translators |
|||||
|
Copyright © 2010 Localization Best Practices - All Rights Reserved |
|||||
The method of automatically updating the TM, and reusing instantly afterward, doesn’t fit well with those who clearly promote the traditional TEP cycle. Yet, for those who want to embrace a non-sequential crowdsourcing approach, the translators’ scrum as I call it, it has its place. The type of content, and the requirement for review and proofing or not, can influence this.
Much depends if the central TM with online updating is done in 1 stage, or in a 2-stage cycle by filling the main pool of TM segments, and then migrating them to a core after they have been reviewed.
There is a benefit in getting reusable segments throughout the translation cycle, rather than waiting until completing a milestone for updating and then propagation. Harmonization and standardization can happen early, however, as you also point out, at the expense of missing valuable QA checks. This can lead to standardization backfire.
Jeff