Hi Christian Schmidt

Unknown said:

Why do I need / want them? To minimize the effort maintaining them. I will have one source language and multiple target languages (maybe 7-10). And I want to have pretty much all the target languages in the one TM file, is this possible?

Neither Studio or GroupShare work this way with multilingual memories.  It is possible to have TMX files with all 7-10 target languages in them, but if you use these in Studio or GroupShare they will be reduced to bilingual memories.

GroupShare has the concept of containers which sit above the memory.  So you could have many TMs in multiple language pairs in this container and just refer to this one container to have all the memories available to you.

Unknown said:

I then could for example load the terminology from: iate.europa.eu/tbxPageDownload.do and transfer this into a TM file (which works. tbx to tmx and then use it as TM).

You could take the IATE TBX and convert this to a single multilingual TMX but when you create your TMs you will indeed end up with multiple Translation Memories.  I covered this idea once here:

https://multifarious.filkin.com/2012/10/22/more-useful-resources-and-multilingual-tms/

As  mentioned, you could create a multilingual termbase which might be more useful in Studio anyway since the data is full of words and short phrases rather than complete translations of sentences.

Unknown said:

Why do I need the TM instead of a termbase? Because of automated translation. Termbase seems very manual based, meaning I have to approve every translation myself. With TM it automatically translates me everything the TM knows. Is there a similar functionality for termbases?

I see where you are coming from, but a TM in this context is very unlikely to do what you need anyway since it won't automatically translate fragments of a sentence which is what you are likely to have with the IATE termbase converted to a TM.  The only way to achieve this is to use something like the Terminjector from the appstore:

https://appstore.sdl.com/language/app/terminjector/759/

I think Trados, the old one, used to have the ability to translate terms in a sentence from a termbase.  It was a little used and very niche feature with some problems such as how to handle synonyms or homonyms which could place the wrong translation, which is probably why it was never taken forward into Studio.  But funnily enough I was asked about this yesterday during a conference in Amsterdam!  Maybe we'll look at the idea as a plugin that's easier to use than the Terminjector, perhaps using a Termbase.

Interesting questions.

At first, thank you very much for your answer Paul. I very much appreciate it.

So, clearly multilingual TM work differently then I imagined. I will see which solution I can come up with. Still I struggle to fully grasp the functionality. What puts me off is the following description:

A server-based translation memory is a multilingual translation memory that is stored on a server. A server-based translation memory can be used by anyone who can log on to the server. Server-based translation memories are accessed through the Internet or through an intranet. Once you have logged on to the server where the translation memory is located, you can work with the translation memory in exactly the same way that you work with local translation memories.

So as it seems to me: I would be able to have a multilingual TM on a Server which, let's say stores 10 target languages and one source language. What prevents me from using this single multilingual TM file in Studio? Meaning: why does it have to be splitted in multiple bilingual TM files when used in Studio? Can't I define the file in my Studio Project as my TM and it uses it as a reference for multiple target languages? (e.g: either when I work with the English and French target language, it should open the same TM file for the job, instead of separated TMs just for the specific target language.

And then, if this absolutely doesn't work... what is the whole point in being able to store multilingual TM on a server, when, as soon as I use them they get splitted up into bilinguals? 

Anyway, I'll read through your article you linked me next and take a look at the Terminjector app. 

I guess I just have different use cases as the regular SDL Trados Studio users. As I want as much automated as possible. Further I rather deal with single or 'few word' segments instead of much sentences. I guess in that regard it seems important to me to use proper TMs that do the job for me. :)

Have to see which solution works best. Thank you very much, again, Paul. 

Hi Christian Schmidt

Unknown said:

So as it seems to me: I would be able to have a multilingual TM on a Server which, let's say stores 10 target languages and one source language. What prevents me from using this single multilingual TM file in Studio?

I think I must be failing to communicate this well to you.  Here's what a multilingual TM looks like in Studio:

So I select this one TM from the server.  This is the container I was referring to.  But if I expand this you see this:

As I tried to explain before I can select my multilingual container called "Roadshow" for a project that has French to German, English and Spanish and that's it.  But these are all bilingual TMs inside the container that manages them called "Roadshow".

I think you have this idea of one TM containing all your languages like the TMS files from the DGT I linked to, or like the IATE Terminology files.  Studio/GroupShare does not work this way.  They are all bilingual, but GroupShare has this added layer allowing you to group several bilingual TMs together.  In fact you can even group multiple source languages as well as target as you can see in the screenshots above.

Does this help you more?

Unknown said:

And then, if this absolutely doesn't work... what is the whole point in being able to store multilingual TM on a server, when, as soon as I use them they get splitted up into bilinguals? 

I hope I answered this question too?  They are already split into bilingual TMs.  They are not as you are imagining them.