Mobile menu

Pages in topic:   [1 2] >
Multiterm from a customer
Thread poster: Antoní­n Otáhal

Antoní­n Otáhal
Local time: 05:14
Member (2005)
English to Czech
+ ...
Jan 25, 2006

I received from a customer a "termbase" folder containing: xxx.log, xxx.xdi, xxx.xdt and two .mdb files (with names different from xx and from each other). I have never received a Multiterm base from the outside; can somebody give me advice what I should do to use these files in the project my customers wants me to work on? (My latest version of Trados is 7.0.0.615 and my Multiterm is 7.0.0.315).

Thanks in advance

Antonin


Direct link Reply with quote
 

Ralf Lemster  Identity Verified
Germany
Local time: 05:14
English to German
+ ...
.xdt and .xml Jan 25, 2006

Hi Antonin,
One of the files is already helpful: the .xdt termbase definition file allows you to create a termbase that's in line with your customer's definitions. It would be best if they provided you with an XML export of the termbase, which you could then import into the termbase created in this way.

To attach the .mdb files provided, you would need the MTMaster.mdb plus the various index files (.mdf and .mtf for each language). I'd prefer using the import, TBH.

Best regards,
Ralf


Direct link Reply with quote
 
pep
Local time: 05:14
English to Spanish
Is <mtf> the root element? Jan 25, 2006

Ralf,

Is the root element of the .xml file you mention?

Pep.

Ralf Lemster wrote:

Hi Antonin,
One of the files is already helpful: the .xdt termbase definition file allows you to create a termbase that's in line with your customer's definitions. It would be best if they provided you with an XML export of the termbase, which you could then import into the termbase created in this way.

To attach the .mdb files provided, you would need the MTMaster.mdb plus the various index files (.mdf and .mtf for each language). I'd prefer using the import, TBH.

Best regards,
Ralf


Direct link Reply with quote
 

Ralf Lemster  Identity Verified
Germany
Local time: 05:14
English to German
+ ...
Nope... Jan 25, 2006

pep wrote:

Ralf,

Is the root element of the .xml file you mention?

...these are separate index files enabling fuzzy search.

Best regards,
Ralf


Direct link Reply with quote
 
pep
Local time: 05:14
English to Spanish
The element was eaten... Jan 25, 2006

Sorry Ralf, in my previous message some text disappeared in the rendered message because I put the element with angle backets, so it was kinda ununderstadable....

Let me try with entities for the angle brackets, I hope it renders well now:

Is <mtf> the root element of the .xml file that you mention (i.e. the file exported with Multiterm).

Pep.


Ralf Lemster wrote:

pep wrote:

Ralf,

Is the root element of the .xml file you mention?

...these are separate index files enabling fuzzy search.

Best regards,
Ralf


Direct link Reply with quote
 

Vesna Zivcic  Identity Verified
Local time: 05:14
German to Croatian
+ ...
Try this procedure Jan 25, 2006

I often receive ready-made DBs. Provided their version agrees with your version of Multiterm, you can do the following:

In Multiterm bar open Termbase/Attach External Termbase/,
locate your .mdb file,
name the new termbase according to your project so that you can easily identify it later on,
finish the step.

Then close Multiterm,
reopen it,
select Termbase/Open Termbase and
select the created termbase from the list that appears.

BR,

Vesna

[Edited at 2006-01-25 19:38]


Direct link Reply with quote
 

Ralf Lemster  Identity Verified
Germany
Local time: 05:14
English to German
+ ...
The answer is still no... Jan 25, 2006

Hi again,
I noticed the display problem, but still...
pep wrote:

Sorry Ralf, in my previous message some text disappeared in the rendered message because I put the element with angle backets, so it was kinda ununderstadable....

Let me try with entities for the angle brackets, I hope it renders well now:

Is <mtf> the root element of the .xml file that you mention (i.e. the file exported with Multiterm).

No, it isn't - thing is, you don't need the root element, as MultiTerm has a pre-defined import format. What exactly are you trying to achieve?

Best regards,
Ralf


Direct link Reply with quote
 
pep
Local time: 05:14
English to Spanish
It was just an unrelated quick check Jan 26, 2006

Hi Ralf,

It was just that I received from one of our PMs an .xml to extract terminology and initially, we just planed to write a simple filter to extract the terms into a cooked tab-delimited text to import in in Xbench, a tool we use internally and that is also public indeed.

But when I saw your message I was thinking that if that happened to be precisely an official MultiTerm xml format, then what we should probably is implement it directly in Xbench without the need for an external program, as it was possible that other clients could send that very same format and it is better to have one tool than two.

The file had precisely mtf as the root element (MultiTerm File, or MTF I thought to myself). So I was just wondernig it if was about time to add that support now that we had a real test file.

We normally add filters to Xbench on an as needed basis, sort of "pulled by demand".

Pep.

Ralf Lemster wrote:

Hi again,
I noticed the display problem, but still...
pep wrote:

Sorry Ralf, in my previous message some text disappeared in the rendered message because I put the element with angle backets, so it was kinda ununderstadable....

Let me try with entities for the angle brackets, I hope it renders well now:

Is <mtf> the root element of the .xml file that you mention (i.e. the file exported with Multiterm).

No, it isn't - thing is, you don't need the root element, as MultiTerm has a pre-defined import format. What exactly are you trying to achieve?

Best regards,
Ralf


Direct link Reply with quote
 
Daniel García
English to Spanish
+ ...
Yes, mtf is used as root element in MultiTerm XML files Jan 26, 2006

pep wrote:

The file had precisely mtf as the root element (MultiTerm File, or MTF I thought to myself). So I was just wondernig it if was about time to add that support now that we had a real test file.

We normally add filters to Xbench on an as needed basis, sort of "pulled by demand".

Pep.


Hi, Pep,

Yes "MTF" is the root element used in the MultiTerm XML format. You can check this easiy by exporting a termbase into an XML file.

You will probably see some other tag names used by MultiTerm like "Concept", "Conceptgrp", etc.

However, in a MultiTerm XML file you will get lots of custom information (field names) or field structure.

You can very easily parse one of these XML files if you know what the field names are and what they mean for that specific termbase. If not, it can be tricky.

I hope this helps.

I think that Multiterm 7 includes an SDK which should detail all this but you should check with Trados/SDL about this.

Daniel

Daniel

[Edited at 2006-01-26 17:37]


Direct link Reply with quote
 
pep
Local time: 05:14
English to Spanish
Thanks for clarifying Jan 26, 2006

Thanks Daniel,

I saw the mighty amount of fields, with plenty of custom fields. Even the status was a custom field (values in german, one of them to indicate that the term was banned, nothing less).

Now that we know that it is Multiterm XML, we'll see if we can work it out somehow directly in Xbench instead of wrting a separate intermediate tool. But the fact that a custom field can ban a translation is a little bit awkward to put it in the interface.

Pep.

dgmaga wrote:

pep wrote:

The file had precisely mtf as the root element (MultiTerm File, or MTF I thought to myself). So I was just wondernig it if was about time to add that support now that we had a real test file.

We normally add filters to Xbench on an as needed basis, sort of "pulled by demand".

Pep.


Hi, Pep,

Yes "MTF" is the root element used in the MultiTerm XML format. You can check this easiy by exporting a termbase into an XML file.

You will probably see some other tag names used by MultiTerm like "Concept", "Conceptgrp", etc.

However, in a MultiTerm XML file you will get lots of custom information (field names) or field structure.

You can very easily parse one of these XML files if you know what the field names are and what they mean for that specific termbase. If not, it can be tricky.

I hope this helps.

I think that Multiterm 7 includes an SDK which should detail all this but you should check with Trados/SDL about this.

Daniel

Daniel

[Edited at 2006-01-26 17:37]


Direct link Reply with quote
 

Antoní­n Otáhal
Local time: 05:14
Member (2005)
English to Czech
+ ...
TOPIC STARTER
Thank you for the advice, even if I am still puzzled Jan 26, 2006

I have always thought that Multiterm is too messy and this feeling is now enhanced. Never mind, let me sum up what I think I know about it now:

When I want to receive a Termbase from the outside, I can either:

(1) import - for this I need the .xdt and .xml files, right? Any other files?

Or is the .xdt and .xml import just an "envelope" I need to fill with the .mdb data anyway?

(2) attach an external base - for this, the .mdb should be sufficent and I can attach it to any other database. Right again?

I am pretty sure that, after working with Multiterm from customers for some time, I will get into the core of the matter, if I have to. My hope was that someone experienced will help me make this process quicker...

Antonin


Direct link Reply with quote
 

Ralf Lemster  Identity Verified
Germany
Local time: 05:14
English to German
+ ...
Pretty straightforward - once you're familiar with it... Jan 26, 2006

Hi Antoní­n,

I have always thought that Multiterm is too messy and this feeling is now enhanced.

I don't quite agree, although I admit that it takes some time getting used to. In my experience, one of the main hurdles is to familiarise yourself with the various concepts involved, which differ significantly from Workbench (not surprising IMO, as the two tools serve different purposes).

When I want to receive a Termbase from the outside, I can either:

(1) import - for this I need the .xdt and .xml files, right? Any other files?

Or is the .xdt and .xml import just an "envelope" I need to fill with the .mdb data anyway?

The termbase definition (.xdt) and import file (.xml) are all you need. If the structure of the import is in line with your own definition, you don't need the .xdt file - most of the time, however, external data will be structured differently from yours.

(2) attach an external base - for this, the .mdb should be sufficent and I can attach it to any other database. Right again?

Nope...
Using your 'envelope' analogy, the .mdb files are envelopes containing termbases - what turns them into MTiX termbases are the index files which are created alongside. Although theoretically it should be possible to attach a termbase in this way, I would not recommend it, as you would have to tamper with your master list (MTMaster.mdb), which may render the data inaccessible.

We have just used MultiTerm 6.2 in a large project involving a 1,500+ termbase - we used export/import to exchange data.

HTH, Ralf


Direct link Reply with quote
 

Antoní­n Otáhal
Local time: 05:14
Member (2005)
English to Czech
+ ...
TOPIC STARTER
Thanks again Jan 26, 2006

(1)
Ralf Lemster wrote:

In my experience, one of the main hurdles is to familiarise yourself with the various concepts involved, which differ significantly from Workbench (not surprising IMO, as the two tools serve different purposes).


I understand the diffrence from Workbench - it is natural, of course. I am comparing to term processing in other CAT tools (TermStar, Heartsome Dictionary Editor) - Multiterm feels overpriced in the sense I have to pay with a lot of effort to understand it (all the various concepts you mention) and what I get in return does not seem really better than something I can get much "cheaper" - well, Trados and Multiterm are widespread, so I do not have much free choice here anyway.

(2)
I would not recommend it, as you would have to tamper with your master list (MTMaster.mdb), which may render the data inaccessible.

We have just used MultiTerm 6.2 in a large project involving a 1,500+ termbase - we used export/import to exchange data.


I do believe that it is better to import; on the other hand, if an agency sends me just a .xdt and .mdb and says "it is OK, you can attach it" – is it adequate if I insist on their sending me the data for proper import? Is there anything like an "industry standard" for proper Multiterm sending and receiving I can refer to?

Antonin


Direct link Reply with quote
 

Ralf Lemster  Identity Verified
Germany
Local time: 05:14
English to German
+ ...
Not sure whether a standard has emerged Jan 26, 2006

Hi again,
I do believe that it is better to import; on the other hand, if an agency sends me just a .xdt and .mdb and says "it is OK, you can attach it" – is it adequate if I insist on their sending me the data for proper import?

I would insist, but then, in the projects I'm involved with, it's usually me sending out data...

Is there anything like an "industry standard" for proper Multiterm sending and receiving I can refer to?

Pass on that one.

Best regards,
Ralf


Direct link Reply with quote
 

Antoní­n Otáhal
Local time: 05:14
Member (2005)
English to Czech
+ ...
TOPIC STARTER
OK, thank you Jan 26, 2006

I appreciate your time. Your advice encourages me to try my best and persuade agencies to send me Multiterm bases in the format you recommend.

Antonin


Direct link Reply with quote
 
Pages in topic:   [1 2] >


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


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

Multiterm from a customer

Advanced search


Translation news related to SDL Trados





memoQ translator pro
Kilgray's memoQ is the world's fastest developing integrated localization & translation environment rendering you more productive and efficient.

With our advanced file filters, unlimited language and advanced file support, memoQ translator pro has been designed for translators and reviewers who work on their own, with other translators or in team-based translation projects.

More info »
Déjà Vu X3
Try it, Love it

Find out why Déjà Vu is today the most flexible, customizable and user-friendly tool on the market. See the brand new features in action: *Completely redesigned user interface *Live Preview *Inline spell checking *Inline

More info »



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