what is recommended TermBase structure: in different files or in a same file ?

Hi all 

What is recommended TermBase structure: 

1. in different domain-specific sdltb files

I this case I am getting lost among many files and loosing track whenever I need them connected to Trados

Screenshot of Trados Studio showing a list of domain-specific .sdltb files with file sizes.

or

2. in the same single sdltb file 

in this case I feel the sdltb file gets oversized if I use fields to specify my language domain for each entry, plus it takes more time for manual manipulations in Excel column

Screenshot of Trados Studio with error symbols next to 'open.sdltb' and 'open.xlsx' indicating issues with the files.

Screenshot of an Excel spreadsheet with a filter applied to the 'Subject' column, displaying various construction-related terms.

Screenshot of Trados Studio TermBase structure showing categories like 'Scope' and 'Contractor' with green checkmarks indicating correct configuration.

Are there any recommendation on how to maintain/keep termbases more efficient in terms of minimum files size / faster search with better translator-friendly approach?

Please share, thank you 



Generated Image Alt-Text
[edited by: Trados AI at 2:16 PM (GMT 0) on 5 Mar 2024]
emoji
Parents
  • Having only just seen this - I thought I would explain how I went about it for multiple customers in a specific field in the dim and distant past. Originally I had separate termbases for each customer, but like you I found having multiple termbases made it very difficult to keep them all up-to-date. In the end, I merged all the customer databases into a single one and used a customer field to separate divergent preferred usage between the customers.

    I use this approach with attribute picklists to separate terminology by supervisory divisions - and have a few extra fields e.g. to help with issues about inclusive language and also accessibility. I did find that I did have a lot of superfluous fields after a while, and recently rationalised some of them (e.g. an abbreviation type field - intended for a mothballed QA idea I had) as the time needed to be invested was not worth it in the end.

    As  mentions, the level of overlap is probably going to be key in your decision (e.g. in your example, having Subpodryadchik three times indicates that there might be some terms that are overlapping!)

    emoji
Reply
  • Having only just seen this - I thought I would explain how I went about it for multiple customers in a specific field in the dim and distant past. Originally I had separate termbases for each customer, but like you I found having multiple termbases made it very difficult to keep them all up-to-date. In the end, I merged all the customer databases into a single one and used a customer field to separate divergent preferred usage between the customers.

    I use this approach with attribute picklists to separate terminology by supervisory divisions - and have a few extra fields e.g. to help with issues about inclusive language and also accessibility. I did find that I did have a lot of superfluous fields after a while, and recently rationalised some of them (e.g. an abbreviation type field - intended for a mothballed QA idea I had) as the time needed to be invested was not worth it in the end.

    As  mentions, the level of overlap is probably going to be key in your decision (e.g. in your example, having Subpodryadchik three times indicates that there might be some terms that are overlapping!)

    emoji
Children
No Data