From mid-October until the end of 2013, I placed two small survey questions at the top of the blog page and publicized these in a variety of user forums. The questions were similar to two posed in 2010, because I was interested to see how things might have changed. This is, of course, an informal survey with a number of points in its "methodology" wide open to criticism, though its results are certainly more reliable than anything one can expect from the Common Sense Advisory :-) My personal interest here was to get an idea of the background readers here might have with various translation environment tools, because it is useful to know this when preparing posts on various subjects. Here is a quick graphic comparison of the 2010 and 2013 results:
Responses to the question about the number of translation environment tools were very similar in both cases. About half use only one, with between 25 and 30% of respondents using a second tool and increasingly small numbers going beyond that. The question posed covered preparation, translation and checking in projects, so some respondents using multiple tools may be translating and maintaining terminologies and translation memories in only one tool. I am encouraged by this result, as it means that despite changes in the distribution of particular tools, users are exercising good ergonomic sense and predominantly sticking to one for their main work. Everyone benefits from this: translators generally work more efficiently without tool hopping, and more effort is focused on what clients need - a good translation.
In 2010, half the respondents cited the use of some version of "SDL Trados" (more details on this were provided in a later survey); the next highest responses at just under 20% were for Déjà Vu and memoQ. Three and a half years later, Atril's share of users appears to have declined considerably, and the use of memoQ appears to be about on par with SDL Trados Studio. OmegaT, an excellent free and Open Source translation support tool capable of working with translation formats from the leading tools, appears to be doing better than many of the commercial tools in the survey, which should not surprise anyone familiar with that software.
Across continues to be a loser in every way. Despite massive efforts in the low end of the market to promote this incompatible Teutonic travesty and the availability of the client software free of charge to its victims (translators), no real progress has been made in the Drang nach Marktanteil. One would expect that a good solution supported by a competent professional development team and a marketing budget, available free to translators, would easily beat the low-profile OmegaT. And I am sure that this is the case. The case simply doesn't apply to Across, which drives some of the most technically competent translators I know completely berserk. The fact that OmegaT is about twice as popular despite its volunteer development and total lack of marketing budget speaks volumes.
More important than any of the individual figures for translation support tools are some of the implications for interoperable workflows that the numbers reveal. Most of the tools listed support XLIFF, so if you use a tool capable of exporting and reimporting translation content as XLIFF, developing an interoperable workflow for translation and review that will work with the majority of tools will probably not be that difficult. An XLIFF file from SDL Trados Studio or memoQ is usually a no-brainer for translation in Déjá Vu, OmegaT, Cafetran or Fluency, for example, and any concerns can be checked quickly with a "roundtrip test" using pseudotranslation or simply copying the source text to the target, for example.
While individual tools have largely improved in their mutual compatibility and ability to share translation and resource data, there is legitimate continuing concern about the increased use of translation servers by translation agencies and corporations with volume needs who manage their own translation processes. Jost Zetsche and I have expressed concerns in the past regarding the lack of compatibility between server platforms and various clients, though with the appropriate use of exchange formats, this can still be overcome.
The greatest challenges I have seen with server-based work is that the people creating and "managing" projects on these servers often lack a basic understanding of the processes involved, so that the skills of the translators competent with a particular client tool may be effectively nullified by an incompetently prepared job. I experienced this myself recently where segmentation, termbase rights and even the source language were set wrong on the server, and the project manager had no idea how to correct the situation. However, things worked out in the end, because I had a playbook of strategies to apply for such a case. In the end, better training and a good understanding of the interfaces to the processes our partners use can get us past most problems.
Post a Comment
Notice to spammers: your locations are being traced and fed to the recreational target list for my new line of chemical weapon drones :-)