Interoperability

Recently there has been a lot of talk about interoperability, and probably it's the word of the year in translation technology. 
At Kilgray we already put interoperability on our flag four years ago, last year we teamed up with Andrä AG, Welocalize and Medtronic to form the Interoperability Now! initiative, and we believe that we need to clarify a number of things before the industry turns interoperability into yet another loosely defined marketing buzzword (just think about whether you can define 'collaborative translation', 'crowdsourcing' or 'workflow' -- now this is what we want to avoid).
 
So here are a couple of points worth considering:
 
1. Interoperability is not about standards. Many people mistakenly put an equation mark between interoperability and open standards. Interoperability means that one tool supports the formats of another, nothing more, nothing less. Full interoperability between two translation tools mean that there is a lossless exchange of data.
 
Standards can help interoperability but they are not the same thing. Standards may be badly defined and not followed by everyone, what's more, certain standards may prevent the advancement of the industry. It is even possible for different tool vendors to implement a standard exactly as specified but that tool A does not support the same standard being used by tool B. This happens with XLIFF 1.2 where the use of extension points means that while the XLIFF adheres perfectly to the specification one tool is unlikely to be able to process another tool's implementation of XLIFF, or the textbook scenario where different SRX-enabled tools supported different flavors of SRX.
 
Forms of interoperability:
 
a. One tool can process the file formats of another. This has been the case of TTX where it was created by one tool but it was supported by many other tools. TTX has never been a standard, but it was an easy-to-parse file format.
b. A tool can create file formats that the other tool takes. Although TTX had never been a standard, Idiom Worldserver could create TTX packages.
c. Two tools can mutually use each other's file formats. XLIFF is such a standard. It does not provide full interoperability in the sense that you cannot open a file in one tool and export it in another. Yet it is a very good carrier format: you can do the preparation in one tool, the translation in another tool and the finalization in the first tool again.
d. Full interoperability. In the field of translation, this has never been reached, and probably it is not even desired. If there was full interoperability, the two tools would need to use the same file filters, and this could have some undesired effects, such as files that are impossible to import into any tool.
 
If you think about interoperability in the field of translation tools, you will find that interoperability (i.e. being able to use data from one tool in the other and when the data is returned, the other tool can leverage it perfectly) is only there for bilingual files. TBX, if it were wide-spread, could provide for interoperability in terminology. For translation memories, there is only very limited interoperability. Ideally, you could take a translation memory created in one tool, import the same file into another tool and get it fully pre-translated. This is not the case in reality. However, this only shows that the translation memory is a secondary resource - it is only there because translation tools are there. The contents of the translation memory shall always depend on the specifics of the file filter.
 
2. Interoperability is a matter of willingness. When we introduced our STAR Transit filter a few years ago, people were very impressed by our focus on interoperability. In memoQ you can import STAR Transit projects, translate them and send the translation back in a package that Transit processes. This was possible because STAR did not prevent understanding their format. While the majority of companies in the industry are relatively open, there are a few binary formats out there, and reverse engineering binary formats may breach copyrights. For a vendor, interoperability means the willingness to go beyond standards. You can go slightly beyond standards by supporting individual flavors of standards (think about our enhanced import of SDL Trados 2007 translation memories that allows to convert inline tags), or you can provide supports for formats that are not standards (TTX, PXF, TXML, etc.).
 
3. Interoperability costs money and may prevent more important developments. It takes time to analyze file formats, implement them, track their progress, etc. If companies only concentrate on interoperability, the industry will not get anywhere. If you can come up with a productivity booster that speeds up work by 10%, but migration will lose you 5% of the data, then forget about facilitating migration by going beyond the basic interoperability, go for the real development. Another reason why companies may decide not to go for interoperability is that it is costly. Planning an interoperable piece of software takes much more time than going for a non-interoperable one, implementing the different nuances also takes time, and supporting interoperable workflow requires a lot of training to support engineers. What's more, interoperability may cut your revenue stream if cheaper tools are used for part of the process. Is interoperability a sales argument? Hardly. For us, interoperability does not really sell -- what sells is our good reputation due to the willingness to allow interoperability. I know of one vendor that decided to simply dump interoperability, and they can sell their software to a specific sector. If you don't need to care about interoperability, you can easily go faster and implement some wow features.
 
4. Interoperability is not just about seamless migration. I heard some people say that interoperability means that you can move from one tool to the other without loss of data. Well, it's more than that. You should also be able to move back and forth without loss of data. And this is when it gets complicated. Currently this scenario only works in practice if you have a 'master' and a 'slave' tool.
 
5. Interoperability benefits the smallest players too. Nowadays most talk about interoperability comes from large translation buyers, but for us the motivation was language service providers and translators. Around 2007-2008, the reason why translation companies bought memoQ was that they could process large SDL Trados jobs in a memoQ server and they could use multiple translators and reviewers at the same time. This is not the only reason anymore, but still a good reason. For translators, the interface matters a lot. One can feel productive in one tool and completely unproductive in the other. Therefore they should have their choice, and the only tools that can give them such a freedom are the interoperable ones.
 
Standards are very good to have, but standards change slowly. The industry should be changing faster. Therefore let's keep an eye on the formats of competitors, and provide support for them, and let's make it easy for our competitors to support our own formats. We will continue to do our best to stay as close to standards as we can - without sacrificing the competitive edges that standards can't accommodate -, and for everything else use a text or XML-based format that anyone can easily understand and create. And we will continue to keep talking to our competitors, and try to have an honest and friendly competition.

Recently there has been a lot of talk about interoperability, and probably it's the word of the year in translation technology. At Kilgray we already put interoperability on our flag four years ago, last year we teamed up with Andrä AG, Welocalize and Medtronic to form the Interoperability Now! initiative, and we believe that we need to clarify a number of things before the industry turns interoperability into yet another loosely defined marketing buzzword (just think about whether you can define 'collaborative translation', 'crowdsourcing' or 'workflow' -- now this is what we want to avoid).