It’s all about the termbase definition when you want to merge termbases, or import data into MultiTerm termbases. The XDT… otherwise known as the MultiTerm Termbase Definition file is the key to being able to ensure you are not trying to knock square pegs into round holes! I’ve written in the past about the flexibility of MultiTerm and it’s this flexibility that can make it tricky for new users when they try to merge their collections of termbases together, or add to their data by importing a file from a colleague.
So what do we mean by definition? Let’s think about keys as I think this is quite a good analogy… the four keys in the image on the right will all open a lock, but they won’t all open the same lock. If you want one of these keys to open another lock then you need to change its shape, or it’s “definition”, to be able to open the lock. A termbase definition works in a similar way because MultiTerm is flexible enough to support you creating your own lock. That lock might be the same as someone else’s, but theirs could also have a different number of pins and tumblers which means your key won’t fit.
I 
I ran a beginners and an advanced workshop at the ATA56 pre-conference day in Miami this year. A really fun day for me as we start the day with no specific agenda or pre-defined course and then try to shape the session to suit the needs of the attendees. The beginner tends to be a little more prescribed, to start off with at least, and the intention is to try and cover the basics of how Studio and MultiTerm work.
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.
Why is MultiTerm a separate program, I can do exactly the same thing with another CAT tool? This is a fairly common question, and it has a very good answer too. It’s because MultiTerm is multitudinous! That is, it can be extended by you to provide a variety of termbases, so many in fact that you could probably create a structure to match anything you liked and you won’t be shoe horned into a fixed structure. As I thought about this the 