Interoperability Now!

For over a decade now, I've been concerned with the interoperability of translation support systems for companies and individual translators in many ways. I became a professional translator after varied activities as a systems consultant, software developer, research chemist, medical technology consultant and sheep farmer in part because of a need at my employer at the time to make diverse systems and processes involving translated content work together with a minimum of data loss and time wasted. This led me to become familiar with Trados, Déjà Vu, Star Transit and a host of other translation environment and support tools, many of which have long disappeared from the active world.

One thing that becomes quickly apparent to anyone involved with more than one of the major technology systems for translation support is the severe limits of compatibility for those with a need to move data between systems and exchange information. In this respect the translation world is decades behind the more mature world of corporate IT, where a mix of systems tailored to solving particular problems is the norm. In the translation world, this is not impossible - many people do it to some extent - but the biggest barrier is the mentality of the people involved. Face it, quite a number of translators are very uncomfortable with technology. Some even hate it.

As someone about to celebrate the conclusion of his fourth decade of working with computerized information technology, I think I can confidently say that I hate this technology more than most translators. For good reason. Back in high school I discovered how an entire day could disappear as I hunched over a CRT to adapt Fortran IV code and update it to run on a timesharing system with Fortran 77; I would start in the morning with sunshine and birdsong, but after a while my eyes ached and my head hurt, and I realized that darkness had fallen without my stirring from the seat of technical torture. When I went to college, I made a conscious decision to use no computers for most of the four years it took to get my degree; I wanted to interact with people and learn things less ephemeral than new system software and computer "languages" (better called  "instruction syntaxes" I think).

I have watched the inexorable forward march of computer technology as it has conquered too many areas of our lives. It has laid waste to far too many of my fifty years. But it has, of course, brought wonderful benefits as well. With a few mouseclicks I can place a free Skype call to family members in faraway California, and we can talk about the latest news, triumphs and tribulations without having to skip meals to pay a phone bill.

One of the greatest burdens for me in all the time I have been involved with IT has been incompatibility of one sort or another. Our societies function best when information is shared freely and accurately. To the extent that IT support this, I find it good, or at least a beneficial evil.

But our lives are ill spent running like hamsters on a wheel from one application to another to accomplish essentially the same tasks; while my life as a translator may be simplified and improved a great deal with the use of a great translation environment tool, it is in no way whatsoever enhanced by the need to use two or more of these for the same tasks. Yet the need to collaborate with colleagues and agencies often drives translators to do this: many of us have licenses for several "CAT tools". And a great many agencies have multiple systems, or their staff go mad trying to make their chosen system work effectively with the babelized translation IT-scape.

It is certainly time for interoperability. Now. Well, yesterday actually, but there's nothing to be done about that except to do it now. Or suffer into the future. At this year's memoQfest in Budapest, Kilgray and a few others introduced the Interoperability Now! initiative and some of its participants. The hour-long session can be viewed here. When I look at the problems of data loss, barriers to collaboration and so many other problems in our field, problems which a few parasites benefit from but which harm most of us, including the "translation consumers" (a dehumanizing term to describe the individuals, organizations and companies who need our services), I can only stand up on my seat and cheer this initiative on.

Although our field's mercantilists would disagree, I think that full interoperability of systems for data exchange without loss and work collaboration would bring considerable economic benefits to the creators and purveyors of translation technologies and rightly so. It might also reduce the waste of resources as companies struggle to create redundant functions best left to the few who would do them well and passionately. If WhizWareZ.com shows the greatest genius for client human interfaces, why should its translation client connect to and work with every major translation work server system on the market, freeing the user to do and learn better things than yet another damned CAT tool. Let the market decide whose terminology module will work best with the next version of the memoQ or SDL or Star server or client. Why should the IT geeks be on call every time a simple exchange of information is desired? There are better ways to spend time and money, so lets invest now with the geeks to smooth the way for the future.

There was one discordant note in the song for the new initiative. An effort of this importance should, if possible, have the participation of a major market player like SDL. And SDL has not been invited to the party. The argument presented for this at memoQfest had, as I recall, something to do with keeping the team lean to pursue a quick resolution of these important issues, and when one considers SDL's history of clumsiness, predatory acquisition and disregard for standards, there is no little reason for caution. However, the past few years have seen SDL open its interfaces and improve the interoperability of its tools, so I do believe that it is worthwhile for SDL technical decision-makers to sit alongside their peers from Andrä, Kigray and other companies and hammer out better tools for trading data among other things.

Even if this does not happen - I can understand the logistical challenges of too many involved in defining these interfaces - I hope there will be a good mechanism for public comment and subsequent revision, so that others - individuals or organization - can contribute their valuable knowledge and ideas. I would like to see the Open Source projects like OmegaT give input as well and implement the standards proposed.