The origin of Chad (if you’re British) or Kilroy (if you’re American) seems largely supposition. The most likely story I could find, or rather the one I like the most, is that it was created by the late cartoonist George Edward Chatterton ‘Chat’ in 1937 to advertise dance events at a local RAF (Royal Air Force) base. After that Chad is remembered for bringing attention to any shortages, or shortcomings, in wartime Britain with messages like Wot! No eggs!!, and Wot! No fags!!. It’s not used a lot these days, but for those of us aware of the symbolism it’s probably a fitting exclamation when you can’t save your target file after completing a translation in Trados Studio! At least that would be the polite exclamation since this is one of the most frustrating scenarios you may come across!
At the start of this article I fully intended this to be a simple description of the problems around saving the target file, but like so many things I write it hasn’t turned out that way! But I found it a useful exercise so I hope you will too. So, let’s start simple despite that introduction because the reasons for this problem usually boil down to one or more of these three things:
- Not preparing the project so it’s suitable for sharing
- Corruption of a project file
- A problem with the source file or the Studio filetype
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 
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.