Termbase translation entries don't show in WB
Thread poster: Lutz Plueckhahn

Lutz Plueckhahn  Identity Verified
Local time: 13:52
Member (2003)
English to German
Dec 9, 2009

Dear all,

Perhaps, this is just an easy one, but I cannot find any solution in the forum.

I have converted some Excel files to termbases 2009 using the SDL Multiterm 2009 Convert program. During this procedure, I was prompted for the index languages and selected English (UK) and German (Germany). After having set up the new termbase using the definition .xtd file generated by the Convert program, and having run the import, everything looked OK.

However, the two index languages appear as ENGLISH and GERMAN (without the regional attributes). For one database, they are even called Source and Target, i.e. just like the fields in Excel.

Although it's perfectly possible to search through the termbases in Multiterm, the Term Recognition function of Transl. Workbench doesn't work correctly: it displays the English terms but doesn't give me the German translations. I'm pretty sure it has something to do with these regional attributes (UK, Germany).

Is there any way to tell Trados to ignore theses attributes altogether?

How do I get these attributes into my termbases? When I add a new termbase without using the definition file from the Convert program, I get errors during the import.

Do I perhaps have to name the Excel columns exactly like the Trados fields?

Thanks in advance for your help!

Lutz


Direct link Reply with quote
 

Grzegorz Gryc  Identity Verified
Local time: 13:52
French to Polish
+ ...
Multiterm import mess Dec 9, 2009

Lutz Plueckhahn wrote:

Perhaps, this is just an easy one, but I cannot find any solution in the forum.

I have converted some Excel files to termbases 2009 using the SDL Multiterm 2009 Convert program. During this procedure, I was prompted for the index languages and selected English (UK) and German (Germany). After having set up the new termbase using the definition .xtd file generated by the Convert program, and having run the import, everything looked OK.

However, the two index languages appear as ENGLISH and GERMAN (without the regional attributes).

It's OK.
You have upper case in Multiterm?

For one database, they are even called Source and Target, i.e. just like the fields in Excel.

The column names shoud be English and German (case sensitive), otherwise the import will not work correctly for standard definitions.
IT's a well known bug.

Although it's perfectly possible to search through the termbases in Multiterm, the Term Recognition function of Transl. Workbench doesn't work correctly: it displays the English terms but doesn't give me the German translations. I'm pretty sure it has something to do with these regional attributes (UK, Germany).

It's possible.
If the regional attributes are different, the term recognition doesn't work.
The safest way is to create a termbase without regional settings.
In this case, the terms should be recognised for all sublanguages.

BTW.
You checked the term recognition settings in WB?
Sometimes Trados selects an incorrect language (the source and target languages are not aligned automatically to WB).

Is there any way to tell Trados to ignore theses attributes altogether?

Post factum, no.

How do I get these attributes into my termbases? When I add a new termbase without using the definition file from the Convert program, I get errors during the import.

Yes, it's "normal".
Your field names are different from the field names in the standard definition.


Do I perhaps have to name the Excel columns exactly like the Trados fields?

Yes.
The Multiterm programmers are unable to map the field names, they rewrite 'em.
It's a common source of problems.

Cheers
GG


Direct link Reply with quote
 

Lutz Plueckhahn  Identity Verified
Local time: 13:52
Member (2003)
English to German
TOPIC STARTER
Workaround/Solution Dec 10, 2009

OK, here's what to do to solve this problem; make sure that the field names are identical to what WB uses - in my case "English (United Kingdom)" and "German (Germany)". The easiest and most reliable way is to use these names already in the Excel file.

Or you leave the Excel file names, do the conversion, and rename the fields when creating the new termbase inside the termbase wizzard.

All other attempts to map the fields correctly must fail, because the programmers obviously have no clue how to handle database relations using the internal index labels.

Best regards - and thanks Grzegorz!

Lutz


Direct link Reply with quote
 
Stefan de Boeck  Identity Verified
Belgium
Local time: 13:52
English to Dutch
+ ...
actually Dec 10, 2009

Grzegorz Gryc wrote:
If the regional attributes are different, the term recognition doesn't work.


This isn't true, actually; at least not in a single pair termbase. I routinely use (both in Suite & Studio) a UK_NL termbase with a US_NL translation memory.

Grzegorz Gryc wrote:
The column names should be English and German (case sensitive), otherwise the import will not work correctly for standard definitions.
It's a well known bug.


It's a well known behaviour that these (Excel column names and Descriptive index fields) should be identical.


Direct link Reply with quote
 

Grzegorz Gryc  Identity Verified
Local time: 13:52
French to Polish
+ ...
Actually it doesn't work... Dec 10, 2009

Stefan de Boeck wrote:

Grzegorz Gryc wrote:
If the regional attributes are different, the term recognition doesn't work.


This isn't true, actually; at least not in a single pair termbase. I routinely use (both in Suite & Studio) a UK_NL termbase with a US_NL translation memory.

Sorry, it is true or we speak about different things.
Just a little test.
E.g., in Workbench (2007 Suite):
I have PL as source and ES-AR, ES-ES and ES-MX as target.
I can select only one sublanguage.
I.e:
I have "kot" (cat) in source,
In the termbase, the term is present for the ES-ES and ES-MX but not in ES-AR.
When ES-AR is selected as target, neither "gato español" or "gato mexicano" are proposed.
In both directions.
I.e. when I put "gato español" or "gato mexicano" in the ES-AR source, the suggestions are not shown.
Of course, the example is somehow artificial but it explains how it works.

As a vast majority of the vocabulary in these sublanguages is the same, this kind of comportment forces an incredible redundancy in the termbase if you really need to handle sublanguages.
IMHO, it's an error in the design.
An easy workaround shoulb be possible in order to propagate a common entry to all sublanguages.

Grzegorz Gryc wrote:
The column names should be English and German (case sensitive), otherwise the import will not work correctly for standard definitions.
It's a well known bug.


It's a well known behaviour that these (Excel column names and Descriptive index fields) should be identical.

If it's not a bug, it's an error in the design.
E.g. I have no problem to map glossaries exported from Passolo in DVX or MemoQ even if the column header is something like "21 1" or similar...

Cheers
GG

[Edited at 2009-12-10 12:49 GMT]


Direct link Reply with quote
 
Stefan de Boeck  Identity Verified
Belgium
Local time: 13:52
English to Dutch
+ ...
but really, actually, now Dec 10, 2009

Grzegorz Gryc wrote:
... it is true or we speak about different things.


We do. As I more or less said in my first reply: “It does work, at least in a single pair termbase.”

The termbase in your example has four languages; how many possible pairs is that exactly? Sixteen? No, twelve, I should think.*

Sometimes you just need to keep things simple (for them to work). Same goes for advice. But, by all means, keep up the good work; I, for one, read your contributions with interest.

Best,
Stefan

* only six, actually

[Edited at 2009-12-10 13:24 GMT]


Direct link Reply with quote
 

Lutz Plueckhahn  Identity Verified
Local time: 13:52
Member (2003)
English to German
TOPIC STARTER
keep consistent Dec 10, 2009

I did some more testing and found that the field names in the termbases have to be consistent. If you just use one termbase in WB, any field name will work. However, if you want to search through several termbases, WB only offers you the field names of one of the termbases (perhaps the first one in the list).

So, if all termbases have the field name "German" (or "Spanish" for that matter), the background terminology seach in WB works like a charm. I've tested this with several termbases.

Best regards,
Lutz


Direct link Reply with quote
 

Grzegorz Gryc  Identity Verified
Local time: 13:52
French to Polish
+ ...
Huh... Dec 10, 2009

Stefan de Boeck wrote:

Grzegorz Gryc wrote:
... it is true or we speak about different things.


We do. As I more or less said in my first reply: “It does work, at least in a single pair termbase.”

Well...
In fact, you're right.
I missed it.
For me, a single pair termbase is an exception...

BTW.
The Autosuggest dictionnaries must match exactly the language pairs, e.g.,
http://www.proz.com/forum/sdl_trados_support/151954-attempting_to_use_the_free_bpm_dictionaries.html
so I was persuaded it's strictly the same with the termbases...

[...]

Sometimes you just need to keep things simple (for them to work).

In fact, I prefer to keep the things simple, so why I rarely use sublanguages.
When I really must make a difference between 'em, I prefer a workaround like this one:
http://www.proz.com/forum/sdl_trados_support/150089-setting_up_new_termbases.html
It's good enough for Spanish but the Portuguese seems easier to handle using sublanguages, the differencies are too frequent.

Same goes for advice. But, by all means, keep up the good work; I, for one, read your contributions with interest.

Thanks

Cheers
GG


Direct link Reply with quote
 

Grzegorz Gryc  Identity Verified
Local time: 13:52
French to Polish
+ ...
Multiple termbases Dec 10, 2009

Lutz Plueckhahn wrote:

I did some more testing and found that the field names in the termbases have to be consistent. If you just use one termbase in WB, any field name will work. However, if you want to search through several termbases, WB only offers you the field names of one of the termbases (perhaps the first one in the list).

The default termbase is always privileged, sometimes in an abnormal way.
E.g. when you have the same hit with two different translations, only the hit from the default termbase is proposed.

So, if all termbases have the field name "German" (or "Spanish" for that matter), the background terminology seach in WB works like a charm. I've tested this with several termbases.


So I do.
I always use English names and almost always generic languages, in this way, I have only one index name for language.

If necessary, I deal with sublanguages using attributes.
http://www.proz.com/forum/sdl_trados_support/150089-setting_up_new_termbases.html

Cheers
GG

[Edited at 2009-12-10 14:16 GMT]


Direct link Reply with quote
 


To report site rules violations or get help, contact a site moderator:


You can also contact site staff by submitting a support request »

Termbase translation entries don't show in WB

Advanced search







Anycount & Translation Office 3000
Translation Office 3000

Translation Office 3000 is an advanced accounting tool for freelance translators and small agencies. TO3000 easily and seamlessly integrates with the business life of professional freelance translators.

More info »
CafeTran Espresso
You've never met a CAT tool this clever!

Translate faster & easier, using a sophisticated CAT tool built by a translator / developer. Accept jobs from clients who use SDL Trados, MemoQ, Wordfast & major CAT tools. Download and start using CafeTran Espresso -- for free

More info »



Forums
  • All of ProZ.com
  • Term search
  • Jobs
  • Forums
  • Multiple search