EntryID during conversion from TBX to XML + XDT

Question

Hello, currently, I'm working on the conversion of a TBX export from an "external" terminology database into the MultiTerm XML format to be able to import the entries into a MultiTerm database. I've tried "MultiTerm 2022 SR1 Convert" (17.1.2185) as well as the GlossayConverter (6.2.8543.33526). Unfortunately, with both applications I'm facing the following problem and I don't know, why it behaves as it behaves. During the conversion process, the values of the "" in the TBX file are written to "XYZ" in the XML. Additionally, in the XML file, at the beginning of each term entry, I get "{ascending number}". The TBX file starts with: " Title

www.ttt.org/.../p>

2023-07-11 07:35:07 UTC

..." In my opinion, the tag "concept" has to contain the value from "

Gerhard Kordmann · Accepted Answer

Always entertaining to see the AI waffling away, but it's wrong. At least for the glossary converter it's not " because this is how these tools are designed to work. ", it's "because there's a bug." 
 It was part of the todo list for the next release, so I had a look today. If you want, you can try the latest beta at https://cerebus.de/glossaryconverter/beta/index.html . As long as the tbx id is numeric, it should behave as expected and use the tbx id directly as the concept id in xml. the conceptId field is never seen by the user. 
 Depending on where you get your tbx from, the id can be nearly any string, like "asl-e4t-99n". MultiTerm can't handle this, so in a strict "No term shall be left behind" policy, the converter creates a unique random numeric value to replace it. 
 Maintaining termbases by merging in changes is a highly skilled job, and keeping ids is just a small step, but least that step can be done a bit more efficiently than making changes manually in notepad ;-)

Edith Wagner · Answer

I ran some tests on my end as well and in my case, the &bdquo;termEntry&rdquo; element from the TBX was correctly converted to the &bdquo;concept&rdquo; element in the XML using MultiTerm Convert. When importing the XML into Multiterm, however, new Entry IDs starting with 1 were indeed created. But this only happened when using the Default import definition. When using &bdquo;Synchronize on Entry Number&rdquo;, the entry numbers from the TBX were used.

Paul · Answer

Nils Jörn It's very hard for me to understand your problem without a better sample file (I don't know the product well enough). So as an example I completed your file with a couple of terms: Title

Source Description

www.ttt.org/.../

2023-07-11 07:35:07 UTC

Auto Car Fahrrad Bicycle Then tested with the Glossary Converter and also by using MultiTerm Convert. I don't think either of them can "force" MultiTerm to use the conceptid in MultiTerm as I think it has it's own mechanism for this. But at least the Glossary Converter can read the conceptid and add it as a new field at the entry level: MultiTerm Convert doesn't see this field at all. Is this what you are trying to achieve? have MultiTerm use the same conceptid as the TBX? I think in this case the TradosAI reply looks pretty good!

Paul · Answer

Nils Jörn 
 Nils Jörn said: Does this clarify my problem a little deeper? 
 Yes... 
 I think the reason why MultiTerm doesn't use the same conceptID as a TBX file is due to the different ways these two systems handle term management. 
 TBX (TermBase eXchange) is a standard format for exchanging terminology data, including concept IDs. Concept IDs in TBX are used to link related terms across different languages. 
 On the other hand, MultiTerm, uses its own internal system for managing and linking terms. 
 When you import a TBX file into MultiTerm using the Glossary Converter or MultiTerm Convert for example, the tool creates a new MultiTerm TermBase and assigns its own internal IDs to the terms. While this might mean that the original TBX concept IDs are not preserved, the relationships between terms are maintained, which is the most important aspect for translation work. 
 I agree it could be useful to have the same ID in Multiterm as the TBX but this idea could unravel over time due to differences in data models between TBX and MultiTerm, potential integration conflicts with other systems, issues with scalability and uniqueness of IDs, increased complexity in maintenance, potential conflicts with future updates to MultiTerm, and potential redundancy if the relationships between terms are effectively maintained without preserving the exact TBX IDs. 
 Nils Jörn said: Let me try to clarify my problem a little: My problem is, that some terms are "doublicated" and (therefore) have different properties/values during updating the MultiTerm database with the XML. 
 What options have you used for the import and can you share a small set of TBX files that would allow us to test and see if there's a way to manage it?

Trados Studio > 3. MultiTerm

EntryID during conversion from TBX to XML + XDT

Top Replies