Translation tool interoperability: Achieving more without the war

A Call to Armistice

Those involved for years with the language services industry have become accustomed to arguments about the best translation environment tools or related programs. To someone familiar with the IT scene for over three decades, these discussions have a very recognizable tone, one often found in the pitched battles between acolytes of IBM, DEC, Sun, Apple and a long list of software and hardware providers too numerous to list in a hefty telephone book. A bit of quiet reflection and a bit more well-grounded understanding then and now, however, lead to the same conclusion: there is no ideal, universal solution to be found anywhere. Some solutions are better on the average for most situations than others, but even the worst tools on offer probably have some scenario which they handle better than any others. Aside from human stubbornness and greed, a good reason why there are so many solutions available for computer-aided translation technology and other IT technologies is that nothing does everything well.

The IT departments of companies came to this realization long ago, not only for practical reasons, but also due to budget constraints. After IT had matured somewhat as a discipline, it was no longer cool to buy the whole package from Big Blue or another source if the mix-and-match approach could produce a better solution for less money. This led to the situation we have today of alliances between vendors co-promoting each others' products and ensuring reasonable degrees of compatibility and interfacing.

Providers of tools to the language services industry have by necessity worked with some common standards, albeit imperfectly in many cases, and have provided compatible or at least semi-compatible solutions for working with file formats from competitors. However, a true commitment to interoperability has not been apparent up to now; such work has typically been presented as a necessary evil if a client expects deliverables in a format out of the ordinary for the translator's preferred tool. There are, however, situations in which parts of a project simply work better with a certain tool and other parts are better done with other software. Sometimes these processing advantages for certain operations are great enough to justify the purchase of software licenses which one does not intend to use to the full extent. What these advantages are in specific situations will be described in later articles, and the judgment of whether they justify learning new software and possibly spending money is left to the reader, who is presumably a competent adult able to make independent decisions and accept responsibility for errors. Each project has its own unique set of criteria, and I make no claim that the techniques discussed will lead to an acceptable solution in every case. The information will be presented as food for thought, which may be of benefit in the some circumstances, and discussion and amendment is encouraged.

I think the time is long overdue to call an end to CAT fights and encourage courtesy and cooperation between solution providers. I would go as far as to call for common interface standards for server communication to allow translators to do client projects on remote servers using the TenT client of their choice. Unrealistic? I don't think so. Solutions like that are not uncommon in mature areas of IT. We need more than browser interfaces. I think that even with the discipline of common communication and exchange interfaces for TEnT data, there is a lot of value to be added by the individual providers such as Atril, Kilgray, SDL and a host of others as they optimize ergonomics and improve data management features.