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 Penrose steps came into my mind. They don’t necessarily have anything to do with terminology solutions for translators, but these steps don’t behave in a known manner either and my mind enjoyed the nonsensical link! I also liked this word multitudinous; partly because of the obvious use of the prefix multi- but also because the use of a word like this suggests complexity to me, and in many ways this is what users think when the subject of MultiTerm comes up.
One of the perceived difficulties in using a multitudinous terminology solution like MultiTerm is the capability that comes with it, and the fact it is a standalone tool (although it’s not needed when using your termbase in Studio to assist in translation) when some translation environments have a simple solution built in. Why is it a standalone tool anyway? The answer to this is quite simple and is best explained with reference to the screenshots below. They are a little hard to read I know, but they are two examples of termbases that contain quite a lot of information and have been created to suit the needs of their users, and this may not be limited to only the translator.
This in itself is quite impressive, but is still scratching at the surface. MultiTerm is what terminologists refer to as concept oriented, and this is a standard method for structuring terminology efficiently. The idea being that the termbase is organised around the concept rather than the words. There are many texts to be found on this subject, all written by far more qualified people than me… but I think it’s important to understand this because it makes clear why MultiTerm exists as a separate product and it’s not just a flat, lexical based, pre-defined set of fields that are part of your CAT tool.
If I take the word “Bow” for example. This could have many meanings in English:
- To bend forward at the waist in respect (e.g. “bow down”)
- the front of the ship (e.g. “bow and stern”)
- the weapon which shoots arrows (e.g. “bow and arrow”)
- a kind of tied ribbon (e.g. bow on a present, a bow tie)
- to bend outward at the sides (e.g. a “bow-legged” cowboy)
If I then look at this in other languages, the different grammatical forms and start to add synonyms then then even at a word level it’s clear how complicated it could get to manage. Taking the same word “Bow” into German with no concept might present at least these terms (and these would all carry synonyms of their own as well):
- die Schleife
- der Bogen
- der Bügel
- der Diener
- die Verbeugung
- die Verneigung
- die Wölbung
- der Flitzbogen
- der Bogenverzug
- der Bügelstromabnehmer
The effort required in managing something like this in a flat facility, or one based on a lexical approach, becomes clear as we can map multilingual terms onto a single concept instead of attempting to map disparate multilingual terms onto each other. So one entry might be the “Bow” in “Bow and arrow”, another the “Bow” at the front of a ship.
MultiTerm provides for all of this, catering for the concept orientation in addition to a structure limited only by your imagination. But to do this effectively and to enable others to use the structure and data you have created you need to have a map! Fortunately MultiTerm will produce and maintain this for you as well in the shape of a termbase definition. This definition can be used to help with the creation of new termbases in MultiTerm and even from spreadsheets as you can build the definition in MultiTerm Convert based on what you find in the spreadsheet. Take this predefined template that comes with MultiTerm in case you need a few ideas as an example:
This is a map, or a termbase definition, for a termbase containing terms in three languages and fields provided to help manage a little workflow around Term Lifecycle Management. So you have different approval statuses for each term in addition to various fields for information relating to the origin and definition of the term itself.
In contrast the map below represents nothing more than source and target terms for a bilingual glossary… and it only took a couple of clicks to create it:
For some users, particularly those who just want a simple glossary of terms, the multitudinousness of MultiTerm may well be unnecessary and overly complex. But for others it’s an essential capability to help ensure the correct use of terminology when authoring documentation, managing catalogs of products and their associated branding as well as being able to provide a multilingual experience for users and translators. But most importantly, when used efficiently MultiTerm can provide the user experience that is demanded. So irrespective of the complexity of the termbase each usecase can be catered for using a variety of layouts that suit the needs of each user.
Now… I really wrote this article as an introduction to MultiTerm and to elicit some ideas on what might make a useful article in the future for anyone looking to make more from this very handy tool in their armoury. I could explain how to create a simple termbase or look at handling data between termbases with different definitions… or I could look at something else altogether. I’m really interested in what topics around Multiterm might be of interest and then I can look at creating some hopefully useful articles around these topics. For example, maybe these sort of things would be interesting?
- Creating a custom termbase
- Importing terms from a spreadsheet to an existing termbase
- Merging termbases
- Using termbases in Studio
I know these sort of things have been covered by people in the past, and there are lots of good resources around as I mentioned in a previous article “Is MultiTerm really that hard to learn?“. But if there are still things that it would be useful to address then let me know. MultiTerm is something I haven’t written much about in the past and I’m up for the challenge!
Hi Paul
Thanks for this welcome introduction into the many facets of MultiTerm. It would be great to learn more about how to manage termbases while in Studio. For example, I have a general termbase on the topic of “political philosophy”. Then I have separate termbases for each of my clients. Some of the terms overlap between clients but some are restricted to individual authors. They are all open for Term recognition when I’m working in Editor view, but I’d like to be able to add new terms to one and not the other, or to all at once. Is there a way to do this?
Best regards
Zakiya
Hi Zakiya, a good topic for discussion indeed. Often the best way to work with termbases like this is to create a field for each client, rather than a separate termbase because then you can use specific customer layouts/filters to achieve what you want. But I can see how making this simple in the same way Translation Memories work would be nice, especially if you maintain separate termbases on behalf of your client. But a good topic, and I’ll do something on this in the near future to explore the options a little.
Hi Paul – nice post!
You raised a pretty interesting topic quite at the end of your post …. namely experiences with mapping of data from different termbase definitions (or so-called entry structures) … did you already dive deeper into this area?
As far as I see – just a dump from my brain – there are several situations that requires to be taken care of:
* a field exists in one definition but not in the other
* a field exists in the one definition but in the other with a different label (but they have the same meaning – for instance “Comment” vs. “Note”) – that’s a straight forward mapping
* a field exists in both termbases, they have the same meaning, but share different values that mean the same … for instance, for “Gender” in one termbase you used English values “masculine”, “feminine” etc. whereas in the other you used German “Maskulinum”, “Femininum” etc. – again, a relatively straight forward mapping.
* a field exists in both definition but they do not have the same meaning (dangerous, false friend!)
* a field exists in the one definition but its according content is split across two fields in the other (applies also to the core category of language “English” here vs. “English Uk” / “English US” there)
* a field exists in the one definition but shows up at a different location in the other (“Definition” below /Language here, whereas below /Term in the other)
* then, cardinality etc. issues – the one field is allowed to show up multiple times in one termbase, whereas it is allowed to only show up once per entry in the other …
… and probably many more.
Any input, ideas – it’s a challenging topic. I like it!
Cheers,
Michael
Well Michael, good to hear from you. It certainly is an interesting and sometimes challenging topic, and you have managed to achieve in your comment the very thing I wanted to avoid! One of the problems MultiTerm has had over the years, and as you spent many years as the Product Manager for MultiTerm you’ll know this, is that you are solving problems for a wide variety of users. But it’s not a 50:50 split. In fact I’d hazard a guess it’s nearer 90:10 with the 90% not being Terminologists at all. So when you describe the sort of challenges you have, the image this conjures up is one of complexity that the 90% either won’t be able to relate to, or just plain don’t want to. This is because the 90% have different needs that are often catered for with a much simpler structure.
This doesn’t mean the points you raise are not important, but it does mean it’s a pretty advanced topic and I think I’d struggle to condense this into a simple blog article to help the 90% get a little more from MultiTerm without adding to any perceptions of complexity that already exist… even when I do run off at the fingertips a little!
So perhaps it’s one to come back to later on… or even one for you to write as a guest post?
Hi Paul,
I think I can agree :-). And – also in congruence with the other comments here – I feel it is rather a question of what the audience is.
MultiTerm, invented by TRADOS in 1990 (for MSDOS …) was originally not only designed for translators, but was targeted towards organisations with quite some demanding requirements in modelling terminology. The latter audience still exists, and TRADOS had quite some success in that market, and SDL, I guess still benefits a bit from this. Though, the business focus of TRADOS and then SDL shifted more towards mainly serving a translators’ / translation processes needs (and MultiTerm was/is affected in this echo); which, I’ve understood by now, is probably from SDL’s business perspective a well justified and good decision.
Yes, for the pure translation process needs I agree with you (and also the other comments). And probably MultiTerm feels too flexible or is not that strict “on rails” for rather simple, straight forward use cases.
Now, mapping termbase definition / entry structures is certainly an advanced topic. But you mentioned it, so I felt free to pick it up :-). Mapping of information, merging of data is a key topic in our work here at Coreon. It is in the institutional world, addressing challenges of cross-border interoperability, harmonisation of existing systems, processes an every day problem. But, indeed it is a different audience that is confronted with these challenges (and, btw, MultiTerm’s capabilities would even not be sufficient for these).
So, where I tend to disagree are just the numbers. Today, for SDL users, it may be 90%/10% split. Years ago, it was not like that – but the times they are a-changin’ …
Cheers,
Michael
Multiterm is a powerful program that suffers from some serious problems: What makes Multiterm such a powerful program also makes it too complex for most simple uses. Leaving aside for a moment the whole Java mess, for most users it is 1) overkill, and 2) very poorly documented.
Overkill because most translators would make more use of a simpler program for their terminology needs (and hence would benefit more from a simpler program).
Very poorly documented because … well go and read the whole mess: even when you know that an operation is possible in MultiTerm (say, importing a simple bilingual glossary from a tab-separated two column file), if you try to follow MultiTerm’s help to carry out the operation you won’t succeed.
My suggestion to SDL. By all means, do keep MultiTerm as your flagship terminology program (for terminologists), but 1) add a simpler program that most people can use easily, and 2) Throw away the whole MultiTerm documentation and have it re-written from scratch by someone who knows well how to communicate with people and how to explain clearly complicated concepts to users (someone like you would be a suitable candidate for this).
MultiTerm is indeed a powerful tool. But that doesn’t preclude it being used for simpler purposes. Interestingly I watched a recorded webinar presented by Michael Wetzel around 2005 where he demonstrated how a simple termbase could be created in MultiTerm in around 30 seconds. So it doesn’t have to be hard, and there are many instructional videos and blogs around today, as well as the OpenExchange applications of course that make this even simpler.
Having said this I do think you have a point, and the help documentation could be better with more example driven information to take users through the features for different processes. This would help immensely as you become more comfortable with MultiTerm as a tool to help you. I’m not sure I’d be the right person though… needs a more thorough and detailed technical writer.
I also think alternative tools will be a good option too. One of the missing APIs for the OpenExchange is the Terminology API. This gap should be filled this year and once we have this it will be possible for developers to create plugins for existing alternatives to MultiTerm, or even create their own. Maybe even as easy as reading off a spreadsheet! I don’t think any of these will replace MultiTerm because the functionality around this tool is far too good and in many cases absolutely essential, but it will allow anyone looking for a simple extension to their autosuggest capability for terms alone will begin to find alternatives that might serve their purpose.
Java should also become a thing of the past as SDL remove the reliance in Studio (not an insignificant effort).
“where he demonstrated how a simple termbase could be created in MultiTerm in around 30 seconds.”
And he probably would also take just as little time to import tab delimited glossary in a new termbase… but if someone who doesn’t know the program already tried to do the same using its documentation, the time required would be a lot longer.
Yes, the help documentation could be better with more examples – so long as it is not written by the same people who have inflicted on us the current version of the help. It really does need to be redone from scratch.
As for opening the OpenExchange APIs to terminology, that’s all excellent news.
Paul, I am sure you are aware that most translators would hardly ever need the advanced features (and flexibility) of MultiTerm; instead, better Studio integration, as in for example, more user-friendly way to add terms on the fly, would be a point to consider. For a more detailed account, you may have a look here: Adding terms in Studio Editor
Of course… and we would have changed the adding of terms to provide a “no check” option as well if we did not have the reliance on the Java applet we do. This will hopefully be addressed. I did write an AutoHotkey script to do this and it works quite well, but it does require a forced delay because of Java anyway. So like this:
;——————————————————————————
; Add term to termbase and save it.
;——————————————————————————
^9::
Send ^{F2}
Sleep, 2000
Send ^{F12}
Return
You run it using Ctrl+9 but you could edit this to whatever shortcut you needed by changing the ^9 at the start. No guarantees though and you may have to fiddle with the sleep value to suit your own setup. Also note that the first time you add the term do it manually as the Java applet always takes a bit longer the first time. After that the AHK script works quite nicely for me.
Paul, after some experimentation I modified the script thus (it would not close the Termbase Viewer window):
;—————————————————————————————————
; Add term to termbase and save it and close the Termbase Viewer window
;—————————————————————————————————
^9::
Send ^{F2}
Sleep, 2000
Send ^{F12}
Sleep, 1000
Click 653 15
Return
I think it will need to be different to suit. The original worked fine for me… maybe just extending the value for the first sleep would do the same thing? Good you managed to make it work anyway.
Paul, the original worked when I reset window layout (so that termbase viewer is an autohide vertical window on top left). The only drawback is the extra time it takes for the termbase viewer to autohide (provided that the mouse pointer is on the right of the screen so that it does not obstruct the autohide functionality).
Paul, I have 2 comments about Multiterm:
– I would like to see MultiTerm Convert built in MultiTerm Desktop and the whole process of creating a termbase from, say, an Excel sheet, simplified, or at least, done within one single wizard.
– I would also like to get a step by step guide on how to (easily) update an existing termbase from the Excel sheet that was used to create it, while new terms have been added to it, or terms have been modified. I always struggle with that synchronisation part, and finally end up recreating the termbase from scratch…
Check this http://www.cerebus.de/glossaryconverter/