COTI… chuckling on the inside

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.

Brief Intro to COTI

Now, I’m definitely no expert but I think a brief introduction to COTI is in order before I show you what the plugin does.  The idea behind COTI is to provide a standardised mechanism for managing the exchange of translatable and reference data between a Content Management System (CMS) and a Translation Management System (TMS).  It does this at three levels.

Level 1

This is all about Translation Packages.  To achieve this level of compliance the implementation of the solution should be able to support the export of a COTI package from the CMS, the import into a TMS and then back again.  You can find an example video demonstrating a COTI Level 1 round trip between SDL Trados Studio and a compliant CMS here.

Level 2

This is still all about package support, but this time with the added requirement of automatic data exchange between the CMS and the TMS to remove the sending around of packages by email or FTP.

Level 3

Now we’re stepping up a notch and Level 3 is all about APIs.  The data exchange must take place using a WebService API so the creation of TMS projects are completely automated.  You can find an example video demonstrating a COTI Level 3 round trip between SDL Trados Studio and a compliant CMS here (you could also use GroupShare or WorldServer for this).

As you can see from the videos Kaleidoscope can provide solutions to all three levels using SDL Trados Studio starting from the simple COTI package plugin which I’m going to look at in a minute, to the more complex automated solution where the SDL projects are created automatically from the CMS and updated in realtime in both systems during the translation phase, and finally sending the translated files back to the CMS without any manual exchange of files/packages taking place.

You can also find the full specification created by DERCOM as part of the COTI Project on their website.  I should also mention that the specification does not state this is for users of a CMS only.  The same package format, or WebService could be used to handle files for translation from any source, potentially providing ready made guidelines for anyone looking to automate their translation workflow; and if they use the COTI plugin they have a free application supporting the TMS side of a Level 1 implementation in SDL Trados Studio already… nice!

COTI Plugin for SDL Trados Studio Professional

Let’s start with a quick reminder that you can find the plugin in the AppStore here, and this is probably a good time to address the mention of “Studio Professional”.  This is because the plugin uses the project automation API and this means that a Professional licence is required.  It also means that for any company looking to use this solution, their workflow would probably be something like this:

COTI Package to SDL Trados Studio Professional -> Creation of Studio package -> send out for translation and then back the other way

Of course any company that only uses Professional won’t need to do this, but I think most will send the Studio packages out to Freelance Translators who will have no problems with a Studio Package.

Once you have installed the plugin it adds a new menu group to the Add-Ins menu here:

Pretty simple really.  So you would click on Import package to bring the files into Studio and have the project created automatically, and Export package after Finalising the Project to add the translated files back into the COTI package for return to the CMS.  The package itself follows this structure which I have taken directly from the specification for COTI:

You can check this for yourself as the COTI package is essentially a zip file, so if you add or change the package name from *.coti to *.coti.zip then you can open the package and get at the files inside.  The reference files are optional so you won’t always see them in the package but the naming conventions are prescribed.  I’ve listed what you might find in them below, but for a complete description please check the specification… this is just to give you an idea of the information that is shared between the systems as part of an implementation:

Package: this is the zip containing all the files needed to create your translation project.  It follows this naming convention
– timestamp
– name given by the CMS
– file extension of “coti”

COTI.xml: this is the package meta file and it contains data created by the CMS and used to support the creation of the Studio project
– project ID
– status
– checkout and due dates
– comments for the TMS project manager/translator
– project name
– project languages

Translation Project: this is the top level folder containing the two subfolders for translation and reference.  The naming convention is:
– project ID
– source language
– target language
The languages follow RFC1766 and ISO 639, so not necessarily equivalent to Studio.  An interesting point of levity, at least I found it amusing, is the introduction to the RFC base which I had not looked at before.  The entire introduction is this “There are a number of languages spoken by human beings in this world“.  I’d say quietly understated!

translation files: this folder would contain all the files that need to be translated for each translation project

reference files: these are all optional, in fact the folder is optional.  It might contain things like DTDs, style sheets, images, reference material etc. (the plugin does not support reference files yet, but I know they’ll be added soon)

That’s about it… so on this basis I think DERCOM have achieved their aim of making this a Common (not proprietary) Translation Interface.  Nice and simple with no bilingual files involved.  So any translation environment could be used to handle these packages to support the workflow with a CMS.  It’s worth noting however that there is no settings file included for converting the source file to a bilingual file which clearly makes sense as every TMS has it’s own proprietary method for converting source files into translatable files.  But it does mean you need to make sure any custom filetypes needed are already available  in your settings.

Back to Studio again… if you click on the Import package icon in Studio you will be presented with a window similar to this:

At this point I click on “Create project” and my Studio project is created.  All I have to do then is translate the files and when I’m done an essential step is to run the Studio batch task to Finalise the project.  If you don’t run this task there will be no exportable files and the window will remain blank.  I’ve completed this task correctly and when I click on the Export Package icon I am presented with the list of exportable files that I can deselect as needed if it’s a partial delivery:

I select the same COTI package I originally opened and the target files are simply inserted to replace the ones that were originally provided.  Now you can send the COTI package back for import into the CMS.  So a very simple process which you can watch in the videos I mentioned earlier.  If you missed the links, here they are again:

Level 1 implementation – manual package transfer

Level 3 implementation – webservice API

Hopefully this was useful for anyone who wondered about automation with a Content Management System and perhaps provides enough background information to ask the right questions if considering an implementation with a CMS.  COTI… definitely nothing to chuckle about!