Every now and then I see an application and I think… this one is going to be a game changer for Studio users. There have been a few, but the top two for me have been the “SDLXLIFF to Legacy Converter” which really helped users working with mixed workflows between the old Trados tools and the new Studio 2009, and the “Glossary Converter” which has totally changed the way translators view working with terminology and in my opinion has also been responsible for some of the improvements we see in the Studio/MultiTerm products today. There are many more, and AnyTM is a contender, but if I were to only pick my top three where I instantly thought WOW!, then the first two would feature. So what about the third? You could say I have the benefit of hindsight with the first two although I’m not joking about my reaction when I first saw them, but the third is brand new and I’m already predicting success!
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.
Strong words… “Committing the Cardinal Sin“!
I can remember from my early days with SDL many interesting, and often frustrating conversations with the then Product Manager for MultiTerm. The almost religious use of phrases like “You can’t use spreadsheets for terminology”… “It only takes a few steps to be able to create a simple glossary with MultiTerm”… “You can’t properly export a MultiTerm termbase to Excel”… and many more discussions along these lines. Well, over the last year or so mainly thanks to the SDL OpenExchange which removes the shackles of being tied to “the way it’s always done” we have seen one tool in particular that has proven this traditional way of thinking wrong. But not because our friendly product manager was wrong… he was mostly right. When you think about Terminology Management in the traditional sense then Excel is not really suited to managing concept oriented databases that are designed for the terminology professional. It has its place, but is definitely prone to error and difficult to manage as the database grows. But what if you only want a glossary?
I first wrote about the Glossary Converter on September 17, 2012… over three years ago. Not only is it a surprisingly long time ago, but I still meet people at every conference I attend who have never heard of this marvelous little tool, and in some cases never heard of the OpenExchange either. So when I toyed with the idea of writing an article about Xmas coming early and talking about the OpenExchange and all the goodies inside, part of me couldn’t resist writing about this tool again. In the three years since it was first released it’s morphed beyond all recognition and today it’s awash with features that belie it’s appearance.
I like to take a little credit for the emergence of this tool because back in 2012 I asked around trying to get someone to create one so that it was straightforward for anyone to create a MultiTerm Glossary from a simple two column spreadsheet… the sort of glossary that most translators use for their day to day needs. I was over the moon when Gerhard (the developer) was interested and created the tool I wrote about back then. But I can take no credit whatsoever for what the tool has become today and it’s well worth revisiting!
When the developer of the Word Cloud plugin for SDL Trados Studio first showed me the application he developed I was pretty impressed… mainly because it just looked so cool, but also because I could think of a couple of useful applications for it.
- You could see at a glance what the content of the project was and how interesting it might be for you
- It looks cool… or did I say that already?
When we want to purchase software what’s the first thing we do? I know what I do… I look around on the internet for websites where I can learn more about the tools I’m interested in and only purchase if I can try them myself, and I imagine you’re no different. If I want to compare TEnTs (Translation Environment Tools) it’s a small and very competitive field and you don’t see the sort of widely published comparisons you might for Office products, or desktop publishing tools for example. So one place to start might be reviews from real users… but can you trust them? They are often written by fans of a particular product who like to rate the comparisons based on their own personal choice, and often the comments they make about other tools are based on not knowing other tools well enough. Certainly when you read the comments from users of the tools that came off worse you can see it’s also quite an emotive area… although it’s good to see users so passionate about their translation tools. Even articles that are written in a well meaning and honest way, such as the one that Emma Goldsmith co-authored with David Turner (comparison between Studio and Déjà Vu) last week, can raise the hackles of some users and if you take a look at the comments you’ll see what I mean!
One of the reasons SDL Trados Studio, and Trados before that, has been such a popular choice for translators and small teams is the ability to work with shared resources. Many Translation Environments require the use of a server solution in order to share work and if you only do this occasionally, or if you work with a couple of colleagues, then whilst the server solutions can offer a lot of additional capabilities they are often over the top for simple sharing needs and may even require you signing up for things you may not be interested in.
Sharing resources at a simple level is pretty straightforward with Studio because they are mostly file based. So you have a Translation Memory (*.sdltm), and a termbase (*.sdltb) for example, both of which can be accessed by several translators at the same time. You may well have read that several times just to make sure this is what I actually said! If this is possible then why do we sell server solutions at all, as we have SDL GroupShare, SDL WorldServer and SDL TMS? The reason of course is that sharing a filebased resource like this has many limitations and it’s not a solution for serious Projects. Limitations like these that are detailed in KB Article #2550 in the SDL Knowledgebase: