tfennell

The basic idea is that the settings at All Language Pair level can be applied across all the TMs you use in a multilingual project in one go.  The specific language pairs allow you to have more control over these same settings by using different ones for each language pair.  Some things can only be set by specific language pair so these settings are at that level.

Hello tfennell ,

In SDL Trados Studio, you will typically select file based TM's at the 'All Language Pairs' Level (Global Settings),

These settings are then use for each language pair contained below (multilingual project)

If I now take a specific language pair- you will see the settings are taken from 'All Language Pairs'

If you wish to use alternative 'Translation providers' and different settings for a specific Language Pair- you are able to do this-

Now you can change the settings (search/penalties etc) for the individual Language Pair- which won't affect the Global settings 

Here for example the original All Language Pairs default setting and the changed Minimum Match Value for the individual language pair.

Hope this helps.

I understand how you would want to set something like formatting penalties or the minimum match value at the All-Language level, and then adjust at the Language Pair level as necessary/desired.

What I don't see is why you would want to ever want to include a bi-lingual, file-based TM at the All Language Pair level.

It would like the option for using or creating a file-based TM should be unavailable at this level, and that it should only be possible to create or use a multi-lingual server-based TM at this level.

I understand all this, but this did not answer my question.  As I said to Paul above:

"I understand how you would want to set something like formatting penalties or the minimum match value at the All-Language level, and then adjust at the Language Pair level as necessary/desired.

What I don't see is why you would want to ever want to include a bi-lingual, file-based TM at the All Language Pair level.

It would seem like the option for using or creating a file-based TM should be unavailable at this level, and that it should only be possible to create or use a multi-lingual server-based TM at this level."

tfennell

tfennell said:

What I don't see is why you would want to ever want to include a bi-lingual, file-based TM at the All Language Pair level.

I thought I'd clarified that point... my bad then.  If you have a multilingual project with 40 language pairs and they all use the same settings (the ones available at All Language Pair level) then this avoids setting them up 40 times.  You have plenty of options at this level too.

Dear Paul,

I trust we will eventually get to mutual understanding.  I fear my question may be so basic it may be causing some cognitive dissonance.

Yes, as I said, I can absolutely understand you would have a 65 percent minimum match value ***setting*** for all 40 languages.

But why would you create or use an EN-fr-FR bilingual ****file-based TM*** at the "All Languages Level?"  It would seem necessary to have *bilingual* file-based TMs created or used for each of the 40 languages at the Language Pair level.

It would seem that only multi-lingual server-based TMs should be available for use or creation at the "All Languages Level."

Is my question more clear now?

Tom

tfennell

tfennell said:

But why would you create or use an EN-fr-FR bilingual ****file-based TM*** at the "All Languages Level?"  It would seem necessary to have *bilingual* file-based TMs created or used for each of the 40 languages at the Language Pair level.

If they were all using the same settings then you would just add all of these 40 TMs in one place, at the All Language Pair Level.

Perhaps you are just reading this phrase incorrectly... it's the place to add "All....... language pairs" when they have the same settings. 

If you like, because you are only working with one TM, you can put it at the specific language pair level.  It doesn't matter at all!  The only time you could see problems is if you mix and match.  So if you use an en-fr TM at all language pairs, and also add one at the en-fr language pair level, then it can cause odd results.  I've seen this when translators receive packages and ignore the message (not as obvious as it used to be in previous versions) that a specific language pair is being used, and the add their own TM at All Language pair level.  So best to use one or the other.

Does this help?

Dear Paul,

I think we may be getting there.  Oh, and I do have more than one TM - I have my big "Mother TM," my "Client TM" and perhaps an "End Client" TM and even an "End Client Matter" TM, and these in 1 or several language pairs. 

Let me put it this way.  I understand that usually I want to configure settings, like

All Language Pairs>Translation Memory and Automated Translation> Search>Minimum TM Match

at the "All Languages Pairs" level.

If I had a multi-lingual Server TM, I would add it at the "All Language Pairs" level

But I see no advantage in putting actual bilingual TMs at the "All Language Pairs" level - this only causes confusion.  Better to put the actual TMs at the "Language Pair" level to avoid confusion and conflicts.

If I had 5 language pairs, putting individual bi-lingual TMs for all these at the "All Language Pairs" level seems very confusing.  Especially if each of the 5 languages has 2-4 TMs ("Mother," "Client," "End Client")

I have been doing a lot of experimentation today with segmentation, and it seems like a TM only has an effect on segmentation if it is placed at the "Language Pair" level.  The only way to have an effect on segmentation at the "All Languages" level is to designate a Language Resource Template at this level.

(I won't go into the sad case of my lost LRT settings here).

Even more confusing, when I try to add a bi-lingual TM at the "All Language Pairs" level, I get the message:
----------------
"This translation memory '4460 PMEM' will not be used for the following language pairs:

Russian (Russia) -> English (United States)

To edit the translation memories used for these language pairs, go to the individual language pair level."
-------------
But then it goes ahead and adds the TM at the "All Languages" level, but apparently ignores the TM settings for segmentation.

The error message is not generated when I use the TM at the Language Pair Level.

It seems like it would be much less confusing to only allow bilingual TMs at the "Language Pair" level and only multi-lingual server TMs at the "All Language Pairs" level.

I see no benefit to allowing 1 or even worse several **purely bi-lingual*** file-based TMs at the "All Languages" level - only additional confusion.

I realize my conclusion may rankle.

I would be very open to any advantages you can state for putting one or several purely bi-lingual TMs in the "All Languages" level, but alas, I have not seen any yet.

Sorry to be such a nag with this, but it would seem very important to get this straight before forging ahead with developing and optimizing workflows that are very much based on the proper use of TMs, especially in the configuration of templates.

I am seriously considering upgrading to Trados PRO, but need substantial clarity in issues like this to move ahead.

If this is an architectural shortcoming of Trados, that is fine - maybe it can be changed in Studio 2021, but if I am missing some advantage from using bilingual TMs at the "All Language" level, I want to understand these advantages.

Thanks once again for your time and attention to this issue.

I know I may be pushing things, but I spend a lot of time on these posts - not to speak of figuring out the Langauge Resource Template issues - if you would be open to a Skype call (which may be shorter) I would be very open to that.  My profile name is Tom.Fennell on Skype.

Best regards,

Tom

tfennell

tfennell said:

But I see no advantage in putting actual bilingual TMs at the "All Language Pairs" level - this only causes confusion.  Better to put the actual TMs at the "Language Pair" level to avoid confusion and conflicts.

You clearly never had to manage a project with 40 language pairs!

But if you see no advantage then don't do it.  Nobody is forcing you.

tfennell said:

I have been doing a lot of experimentation today with segmentation, and it seems like a TM only has an effect on segmentation if it is placed at the "Language Pair" level.  The only way to have an effect on segmentation at the "All Languages" level is to designate a Language Resource Template at this level.

Incorrect.  The vast majority of users don't use the specific language pairs at all so I think we'd have noticed ;-)  Segmentation takes place based on the first TM in your list at the All Language Pairs level.

tfennell said:

Even more confusing, when I try to add a bi-lingual TM at the "All Language Pairs" level, I get the message:
----------------
"This translation memory '4460 PMEM' will not be used for the following language pairs:

Russian (Russia) -> English (United States)

To edit the translation memories used for these language pairs, go to the individual language pair level."

Just informational because you have done what I said is a bad idea... mixed and matched.

tfennell said:

I realize my conclusion may rankle.

Not really.  You can do whatever you want.  I'm just trying to explain to you how it works.

tfennell said:

I would be very open to any advantages you can state for putting one or several purely bi-lingual TMs in the "All Languages" level, but alas, I have not seen any yet.

Well... I don't really need to convince you.  But the obvious is that you don't work with enough language pairs and you probably don't use many of the available features.  If you did then not having to change the Search settings, TM penalties, filter penalties, field updates, match repair settings or even verification options on every TM would be a blessing.

tfennell said:

I am seriously considering upgrading to Trados PRO, but need substantial clarity in issues like this to move ahead.

Why?

tfennell said:

I can understand why you would set up default, "Mother" TMs for each language pair, both in the Options window and in Project Settings.

Hi tfennell

I wonder, do you know that settings made in Project Settings overrule the same settings in your Profile settings made via File>Options? 

This is because you can use File>Options to set stuff you want to use unilaterally in projects you create from your own Profile settings.

Then, Project settings are useful because you can make them client-specific, subject-specific, context-specific, etc., via project templates you can create at the end of a customised project setup. They are also useful because incoming project packages from clients come pre-set with the client's requirements.

The All Language Pair level is a teensy bit like this, it applies to all TMs in a project unless there have been settings added via the specific language pair, which then overrule it. A point I'm not sure you have appreciated?

Regarding upgrading to Studio Pro, go for it! I had forgotten what it was like to work with the Freelance version until I went back to Freelance Studio 2014 to find screenshots to help someone who was still working with 2014. There is SOO much more functionality with Pro that you miss when you go back to Freelance... you won't look back, honestly. Not unless you're having a memory lapse... 

I've been working with SDL Trados Studio and MultiTerm since the very first versions (and TagEditor/Workbench/MultiTerm before that) and they are great products. The essential thing is to fully learn the functionality that you specifically need. The whole repertoire of what these products are capable of is huuuge. Better to learn just what you need and make it work for you. Computers and software are tools. Like any tools, they work best when you use them for what you personally want to do.

I hope the above makes good sense... Go for the pro version, you won't regret it if you make it work for you.

All the best,

Ali