Once upon a time, in my youth, communication, including translation, used media that were more or less common standards. Any pen or pencil could write on most any paper or vellum, and while one might have preferences in a brand of typewriter, the choice mattered little to the end result. Transmission by postal mail, courier, teletype or (later) fax also used mostly compatible protocols, and fewer things got lost in the pile of junk mail, as the kinder, gentler form of "spam" was called in those days.
Then the rise of IT and media technologies in the commercial and consumer world shattered this pax, and a myriad of information fiefdoms rose and fell, with users as the foot soldiers and cannon fodder in their conflicts. Eventually, on the main stages of IT, the vendors were forced to realize that their futures depended not on information fortresses but in open exchange and interoperability.
In IT backwaters such as the translation "industry", old practices persisted like medieval kingdoms and customs around the Himalayas, but eventually modern data sanitation reached even this provincial niche, which had adopted some computer tools while ignoring most best practices to maintain proprietary strangleholds. But eventually, the march of progress reached even those altitudes, and TMX, TBX and XLIFF became common parlance. And all is well or shall soon be. Really?
In the 203rd edition of his Tool Box Newsletter (premium version), Jost Zetzsche discusses a recent article in Forbes magazine (Cloud Computing's Vendor Lock-In Problem: Why the Industry Is Taking a Step Backward) and its implications for IT service consumers, including those involved in the translation business. The original article and Jost's commentary are very much worth reading (which is why I subscribe to the full content of his newsletters). His insights included the following comment:
"While we have data exchange standards that are more or less well supported (TMX for translation memories, TBX for termbases, XLIFF for the translation data, and the upcoming Linport for translation packages), there are no mechanisms that enable tool A to enter into the server- or cloud-based workflow of tool B. So, if your client sends your project not as data but as a login that you can use within a tool to access an online-based project or -- even more simply -- to actually log into an online-based tool that automatically gives you access to online-based data, all the hard-fought-for advances in widely accepted data exchange standards are nullified."
This is one of the problems which has concerned me, along with the loss of platform freedom for translators currently wanting to work on server-based projects. Although I know some translation companies, such as Translators International in the Netherlands, who use their server-based memoQ and other technology to make translatable content available to their language pair teams in a variety of best practice, compatible formats, in too many cases, server-based projects lead to a kind of lock-in which ultimately is in no one's best interest. Across Systems, with its wicked policy of deliberate incompatibility, represents the worst case I know, because it is not even possible to work with data exports of some kind as one can with respectable systems such as some SDL technologies, memoQ, Ontram and others.
Various influencers within SDL, Kilgray, Atril, MultiCorpora, Andrä AG and elsewhere are probably quite tired of hearing me pluck the strings of my dream harp loudly and repeatedly in their presence: I want to see online server communication standards which enable a client user of Trados Studio or Wordfast Pro to connect to a memoQ Server project, or someone with a memoQ Translator Pro installation to connect to an Ontram or SDL server project and work most effectively using the ergonomic tools with which the translator or editor is most familiar. I don't buy the arguments of "difficulty" at face value; just look at all the integration plug-ins that are being released by various vendors, with remote TM or termbase access, and it's fairly obvious that at least some degree of online interoperability should be achievable without much pain.
Jost's commentary concludes with a quote from the Forbes article: "Only one thing will eliminate or reduce the risk of vendor lock-in in the long run: if end-user customers start demanding standardization and interoperability, just as they have in the past with on-premises applications... providers will fall in line."All of us - individual translators, translation companies and corporate customers who manage their own translation services with server-based technologies - need to demand that all the credible providers of translation environment technologies "fall in line".
