Probably you’re all far more educated than me and when you read COTI you probably didn’t think “chuckling on the inside” did you? I googled it and looked at four acronym websites, none of which found the correct definition… but two of them returned the title of this article so it must be right!! Oh how I wish it was… just to bring a little levity to the ever so serious tasks of interoperability. But no, it stands for Common Translation Interface (COTI). This is a project pioneered by DERCOM which is the “Association Of German Manufacturers Of Authoring And Content Management Systems”… so nothing to be amused about there!
The subject of interoperability is in fact a serious one and many tools like to claim they are more interoperable than others as a unique selling point for anyone prepared to listen. It’s also a big topic and whilst I am always going to be guilty of a little bias I do believe there isn’t a tool as interoperable as the SDL language Platform because it’s been built with support for APIs in mind. This of course means it’s possible for developers outside of SDL to hook their products into the SDL Language Platform without even having to speak to SDL. Now that’s interoperability! It’s also why I probably hadn’t heard of COTI until the development was complete and I was asked to sign a plugin for SDL Trados Studio by Kaleidosope… outside of SDL I think they are the Kings of integration between other systems and the SDL language portfolio.
Read More
Everyone knows, I think, that an SDL Trados Studio package (*.sdlppx) is just a zip file containing all the files that are needed to allow you to create your Studio project with all the settings your customer intended. At least it’ll work this way if you use Studio to open the package… quite a few other translation tools these days can open a package and extract the files inside to use but 
… and path handling in Studio can still be a little challenging. I imagine that’s a statement not too many users would disagree with! There is a knack to using it, and if you can allow Studio to do its thing, which is what the black box translation environments of some competitive solutions do anyway, then it is something you can live with. But if you want to have the physical Studio projects set up in the same way as your customer folders, which the black box approach can’t do, then Studio can be a little frustrating at times when in your eagerness to tackle the work your projects are stored in a location you didn’t intend because you missed the prompts to change it! I even wrote about this once in an effort to explain the inner workings of path handling in Studio, “
I think I’ve discussed Project Templates in the past, although perhaps only in passing. So let’s start off by painting a picture of the situation you find yourself in where templates come in handy. You maintain your own Translation Memories, in fact you have five you regularly use for every project but keep them separate because they are based on different sublanguages and you have some clients who adhere strictly to the minor linguistic differences. You have a couple of termbases that you also like to add to every project and you find it easier to manage the terminology for your clients in separate termbases rather than use custom fields that complicate the ability to import/export with your colleagues. You also have very specific quality assurance rules that you’ve honed over many years of translating and you know these are reliable and help you when you work.