Poll: Barriers to Cooperation

Recently in the sidebar of this blog, the following question was asked:

What are the significant barriers for you in collaborative projects with colleagues?


The responses were distributed as follows:

12%    None. I do it all the time without trouble
25%    Organization: coordinating & scheduling tasks
29%    Technology: suitable means and methods of resource sharing
45%    Networking: I don't always know suitable people to work with
31%    Trust: I'm afraid of having clients stolen or being held responsible for the failures of others
6%    Other reasons

It's interesting that the most frequent response indicated a lack of suitable partners for cooperation. Whether this is a perception issue or a real matter of getting out and getting to know qualified peers is probably very much an individual issue. In my case I simply don't know a lot of linguistically qualified German to English translators with a significant knowledge of chemistry and related sciences and a healthy dose of legal competence. When I see otherwise very good translators going at such texts armed with a dictionary and boundless confidence, I can't help but cringe, especially if I'm involved in the review somehow. I have bad flashbacks to the day that a superb legal translator took on an IT text on entity/relationship modeling and asked me if some key term had the same meaning as it does in contracts. Not even close.

Trust was another major issue. This was not unexpected given the paranoia I observe at times in various fora. I don't worry much about client "theft" and often freely pass on contact data for qualified colleagues, with the understanding that the parties involves in any transaction bear all the responsibility for the results. Concerns about responsibility for bad quality from others is understandable, but here proper project management - enough time allowed for review and rescue and a sufficiently high margin to allow for any contingencies - can offset a lot of potential trouble. This is an important organizational issue that many freelancers are neither prepared to qualified to handle, so caution in this regard is probably praiseworthy.

Technology as a barrier is more a matter of knowledge than the actual technology available. Not everyone has the resources or inclination to maintain a translation server with SDL solutions, memoQ, Déja Vu or other options, but new entries to the market like Wordfast Anywhere (a free collaboration tool with privacy features) could be game-changing here, and little birds tell me that SaaS solutions may soon be available at affordable cost for small freelance teams. About a year ago I had the pleasure of being involved in a nice project where a memoQ server license was leased for a month; the only down side to that was the hardware problems the project coordinator had figuring out the IP addresses with his router. Technical options for collaboration outside of agency structures are increasing, and it is worth investigating developments in this area. In one case we brought a collaborative project to an agency that had the necessary infrastructure (a memoQ server), and the results were quite satisfactory, so this is one option that may be worth exploring with small, flexible LSP partners.

The challenges of coordinating and scheduling can be considerable. Many freelancers lack experience as project managers and may not have had occasion to develop the necessary interpersonal skills and "toughness" to deal with difficulties that may arise. The *technical* aspects of assigning, scheduling, coordinating and delivering jobs can be handled adequately with affordable software solutions. The best option I currently know for this is the Online Translation Manager (OTM) from LSP.net, which for a basic monthly fee of 29 euros per month gives anyone full access to all the IT infrastructure needed to run an agency of any size. It's "software as a service" with automated backups and top-notch security; the cheapest option for setting up my own server and other software adds up to several years of OTM fees at the very least. OTM also gives me completely secure file transfer for clients and cooperation partners. This is important for paranoid patent lawyers and others. I've been looking for and testing solutions in this area for seven years now, and although there is still significant optimization needed by the provider for the average freelancer or small team, OTM is the best option for small teams looking to grow on a budget or medium-sized LSPs who need competence, security and cost control. The provider currently offers free trials to interested parties.

Of course, collaboration isn't for everyone. I'm often of two - or even three - minds on the subject. But for those who are interested in working together with others as a way to grow their business, there are many options and many exciting developments ahead.

Results of the Trados user survey

After my first fling with the Google Blogger polling tool, I decided to look a little more closely at the breakdown of the "Trados users" who had responded to the poll.

The new poll asked about the use of various Trados versions. Personally, I use two older versions (2007 & 2006) and once in a while I trot out MultiTerm 5.5 for clients with Stone Age termbases. I'm still testing Studio 2009, though most of my objections have been dealt with adequately over the past year, and if good people like Paul Filkin and Roger Lai can effect a change of culture at SDL Trados so that insulting marketing campaigns like the disgusting "amnesty" a while back are not seen any more, I could envision myself accidentally recommending an SDL product beside MultiTerm or Passolo for productive use. It might take a lot of Unicum to get there, however.

But SDL Trados Studio 2009 looks good on a netbook for the most part. I'll have to give them that. The Hungarians in whose technical footsteps they follow have some optimization to do for that environment. And as requests for Studio 2009 projects pick up, I'll inevitably look more closely at interoperability issues with that environment, and from what I've seen so far, I don't expect to be terribly irritated.

The responses in this poll were not exclusive (as anyone with rudimentary addition skills can discern). So someone who uses both the latest version and the previous one for various clients should have (and presumably did) mark both responses. To me, the results indicate however shakily (due to the low number of poll responses) that SDL has moved successfully to the new generation of technology and established a sufficient base of licenses that it will remain viable for the present generation of translation environment technology. That was to be expected given the momentum involved. But there remains great skepticism among the old user base, and when I talk to agency owners who describe the technical challenges they face with data conversion and interoperability, very often I must point out that what they are looking for is currently offered only by the memoQ Server at a friendly price that might make those who invested in other TM server technologies reach for the Alka Seltzer. In one big Berlin agency I'm close to, the license for SDL Trados Studio 2009 was purchased months ago, but there's no hurry to install it as the project managers ask me to write up procedures for Déjà Vu and memoQ to handle insane character mapping problems for Java properties files in Greek, which the last Trados 2007 could no longer handle well. I assume Studio 2009 can deal with the problem, but the trust seems to be gone. Similar reservations have been expressed by other agency owners who have used Trados since version 1 and are frustrated that when problems arise, the chaps on the support line know far less than they do and read from a script. Meanwhile, in the Wild East, software-slinging CEOs and heads of development still provide competent, detailed, personal support for devilish technical challenges at odd hours.

On the whole, I would say "good job" to SDL for having kept so many users "in the boat" by getting them to buy Studio 2009 licenses. And I hope they can keep them there by expanding the usefulness of the product for all by not only improving its performance (use of resources) but also all aspects of interoperability so that it can become a true universal work tool for translation, even including connectivity to other server systems for its desktop users. To the extent that one can claim any tool provider is in that race, they are not yet in the lead.

Results of the June translation tools surveys

At the end of May I discovered that a new widget had been added to Google's Blogger tools, which offered me a simple way to conduct single question polls. I had been wanting such a feature for a while, so I promptly tested it with a poll on translation tools used (the one on the bottom in the graphic at the left) and followed it a few days later with a question on the number of tools used routinely when it occurred to me that they were a number of others like me who make routine use of multiple tools. As I see it, the responses to that question are also important when considering the significance of responses to the other question. The initial trend of the results remained fairly constant throughout the month, even with a large surge in responses after Alex Eames kindly mentioned the polls in his last tranfree newsletter.

Over 40% of respondents use more than one translation environment routinely. (Astute readers may note that the percentages don't add up. Google's programmers are obviously fond of new math or at least screwy rounding and truncation.)  This would include people who actually translate in multiple environments as well as those who use environments other than their favored one for project preparation and QA. My partner is a good example of this latter category; she uses "classic" Trados all the time to export TMs and terminologies provided to her, pre-segment Word/RTF and TTX files for translation in Déjà Vu X or memoQ and to perform tag QA on TTX files. Probably a few other things too. But after she learned the benefits of more modern translation environments, I would risk singing soprano if I suggest that she actually take up translating with the Trados Workbench macros or TagEditor again. Maybe I can get her to look at SDL Trados Studio 2009 one day, but first I think I'll take up something safer like mud wrestling with crocodiles.

The 8 to 12% of respondents who indicated that they use no translation tools is probably well under the true figure in our profession. My blog tends to attract readers with an interest in the technology of translation and not so many who like to contemplate flowery phrases for translating obscure poetry (too bad, really - that's more my taste, but first bills must be paid). But since one of my intentions in creating these polls was to get an idea of the technology interests of my readers and perhaps choose some future topics to reflect these interests, I'm not really concerned about an accurate representation of the full population of translators. The profession is simply too diverse and fragmented for me to care. It's interesting to see that I belong to the 1% of nutcases that use 5 or more tools - I can hear I told you so on this one already from many quarters. And I like to think I'm not a nerd. Einbildung ist auch 'ne Bildung.

In the poll on specific tools, I received some criticism for not including certain tools under a category more specific that "other". As you can see, with a grand total of 15% other, I'm probably not missing much there. When I see interesting minor tools I'll certainly mention them if I can do so with some knowledge, but I don't have the time to offer the extensive expert surveys that you'll get from a guy like Jost Zetzsche and his Toolkit newsletter or book on computer skills and tools for translators.

I probably also should have split the Trados part of the question into at least the new and old generation of SDL products, but I simply didn't think of this until a few days after the poll was running, and I decided to deal with that issue in a follow-up question another day (and I have - see the poll in the left sidebar, which will run until August 1st). This is also relevant to me, as I'll be exploring the no-longer-so-new Studio 2009 version more in the future. (Why call it 2009 still when you release the service pack that actually makes it work in 2010?) It may run like a lame pig on many machines, but I do like some of the interface elements a lot, and it's the best program on netbooks I've used as far as critical parts of screens and dialogs not usually getting cut off.

If the poll statistics even roughly approximate the real distribution of tools among commercial translators, then the perception that "everyone" uses Trados is certainly not even close to correct. The greatest share of licenses is certainly for some version of Trados, but if one considers the number of people who use it as I do primarily for some of its filters and to prepare projects for clients who ask for Trados uncleaned deliverables, then the percentage actually translating with Trados will be far under 50%. This is a point well worth considering for those who want to use the most qualified translator for a given subject: statistically, the odds are against you if you insist on Trados use. It's far better to design projects in a tool-neutral manner as far as practical and let the translators work with whatever they feel most comfortable with. The importance of using the best qualified translator for a particular subject rather than the first monkey with a particular tool in his box is one of the reasons why I like Déjà Vu X and memoQ so much: the RTF table exports from these two tools allows projects to be translated or edited by anyone with a modern word processor regardless of the source format. Every translation environment tool should follow the example set by Atril and Kilgray in this respect.

It's also interesting to note that "major" tools like Star Transit and Across only have 6% of respondents claiming use. Anyone who tries to insist on a translator using those tools is playing a very bad hand.

The main conclusion I draw from these data is that give the diversity of tool use among qualified translators, it is more important than ever to design and test our processes for true interoperability and to drop the religious insistence on the use of One True Tool, no matter what that tool may be.

But that's just my initial reaction to the data. What do you think?