Hi Nils - I am wondering if our cloud-based terminology (called Trados Terminology) might be a better choice now for this kind of use case. Its API is described here: Trados Cloud Platform API Documentation.  Another alternative could be to use the REST-based API for server-based termbases - I think you can access its documentation on our public GroupShare server at https://groupsharedev.sdlproducts.com/documentation/api/index#/. Thanks, Daniel

Hi Nils - I am wondering if our cloud-based terminology (called Trados Terminology) might be a better choice now for this kind of use case. Its API is described here: Trados Cloud Platform API Documentation.  Another alternative could be to use the REST-based API for server-based termbases - I think you can access its documentation on our public GroupShare server at https://groupsharedev.sdlproducts.com/documentation/api/index#/. Thanks, Daniel

Good morning Daniel Brockmann ,

thank you very much for your soon reply.

Why are you wondering if the cloud-based terminology might be a better choice for this use case? Why could Trados Terminology be a better choice for us? And would it be a replacement for our MultiTerm/GroupShare server?
Unfortunately, I'm not that familar with all the different RWS tools (MultiTerm, Trados Terminology, LanguageWeaver, ...).

We're using MultiTerm in addition to Passolo for translating our applications and get a tbx export from another terminology database which isn't compatible with Passolo. Therefore, we're currently using MultiTerm.

Thank you very much in advance for your further informations.

Best regards
Nils

Hi Nils - because you mentioned thread safety - I guess desktop APIs cannot be as robust as server- or cloud based REST APIs with scalability and robustness built in by design. We have products for all ways of working - local, server/on-premise, cloud - and I was just pointing out that in your particular case, the GroupShare REST API (with terminology-specific REST calls) or cloud based terminology might be a potential future path. For the Passolo context, the GroupShare REST API might be worth a look as you have it already anyway. Thanks, Daniel

Hi Daniel Brockmann ,

thanks for your update. Do I understand you correctly that we could also import the terminology data into our MultiTerm server database using the GroupShare REST API? Then that would probably be a really good alternative to a command line tool.

Best regards
Nils

Hi Daniel Brockmann ,

one additional question regarding the documentation. In the documentation of the Trados Cloud Platform API (https://eu.cloud.trados.com/lc/api-docs/termbase-import-export) it is mentioned, that "Only empty termbases support importing content.".
But, a few lines later at the "duplicateEntriesStrategy" parameter : "override The content of the current entry with the same identifier will be replaced by the imported entry."
If the termbase must be empty to be able to support importing content, which content could be overwritten?
Do I misunderstand the documentation or is that a failure in the documentation?
Thanks in advance for your clarification.

Best regards
Nils

Nils Jörn 

Just want to make sure you don't confuse the Trados Cloud API with the GroupShare REST API.  These are completely different products.

As far as I am aware the GroupShare REST API is designed more for individual term management and search operations rather than bulk data import scenarios.  For true bulk imports, the traditional MultiTerm Desktop approach remains the most practical and efficient method.  So your original question may still be relevant,

The GroupShare REST APIs only make this available:

• Individual concept management: POST /multiterm/api/1.0/termbases/{termbaseId}/concepts - Add single concepts
• Concept updates: PUT /multiterm/api/1.0/termbases/{termbaseId}/concepts - Update individual concepts
• Concept deletion: DELETE /multiterm/api/1.0/termbases/{termbaseId}/concepts/{conceptId}
• Search and retrieval: Various endpoints for finding and retrieving terminology
• Multimedia support: POST /multiterm/api/1.0/termbases/{termbaseId}/multimedia - Add images/media

What's Missing:

• No bulk import endpoints for file-based imports (XML, TBX, CSV, Excel)
• No batch concept creation endpoints
• No import definition management via REST API

I'd love to be corrected, but I'm pretty sure this is accurate based on the documentation we provide.

Nils Jörn said:

one additional question regarding the documentation. In the documentation of the Trados Cloud Platform API (https://eu.cloud.trados.com/lc/api-docs/termbase-import-export) it is mentioned, that "Only empty termbases support importing content.".
But, a few lines later at the "duplicateEntriesStrategy" parameter : "override The content of the current entry with the same identifier will be replaced by the imported entry."
If the termbase must be empty to be able to support importing content, which content could be overwritten?

A good question... the documentation does contain conflicting statements:

• "Only empty termbases support importing content" - This suggests imports are restricted to empty termbases
• Duplicate entry strategies (ignore, merge, override) - These options only make sense if the termbase already contains entries

Perhaps Patrick Andrew Hartnett can confirm whether this is a documentation error or duplicate strategies that might be describing intended functionality that isn't fully implemented yet?

Yes, my bad - I was under the impression we can do bulk imports in the MultiTerm Server/GroupShare API but we don't, apologies Nils. Thanks, Daniel

Good morning Paul Filkin ,

thank you very much for your detailed answer. 

Then, my original question is still relevant. I'd love to get an answer if the MultiTerm API is thread save and if it's possible to run the .ProcessImport method in a new thread.
And even, how to verify if the import has been successful, according to my other question here: community.rws.com/.../how-to-verify-if-database-import-or-export-by-api-has-been-successful

Best regards and have a great start into the new week.
Nils

Hi Nils Jörn , thank you for raising this.  We'll need to review the documentation and remove that statement here, where is suggests "Only empty termbases support importing content".  Importing terms to an existing termbase with terms is supported, as you suspected.

It's possible that an early release of the Public API had this limitation, and this statement got overlooked.

I have alerted the team of this and they will update the documentation with next public release.

Internal ref: CRQ-43524

Nils Jörn said:

Then, my original question is still relevant. I'd love to get an answer if the MultiTerm API is thread save and if it's possible to run the .ProcessImport method in a new thread.

Hi Nils Jörn ,  I suspect that the short answer is no.

Simply because I know that Multiterm is a COM automation API, which use STA (sinle theaded aparment), e.g. not guarenteed thread safe. From experience, calling COM from MTA or attemptting to marshel it accross threads more often leads to unpredictable behaviour.  I'm old enough to simply not do it  anymore, I like sleeping and not working/debugging all night :-)

I would recommend:

• Use it from a single STA thread only. Do not create objects on one thread and call them from another like you're attempting here.
• ProcessImport is a synchronous, blocking COM call. I suspect that there is no supported way to cancel it mid-call or safely abort the thread.
• If you need a hard timeout/cancellation, run the import in a separate helper process and kill that process on timeout.

 Daniel Brockmann  can also confirm this with the multiterm team directly?  although, I'd doubt the answer is different to what I'm writing here.

Thank you Patrick Andrew Hartnett  - confirmed. Thanks, Daniel