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
  •  

    In the absence of a comment from anyone else... my view would be to keep it simple!  The more complex you make it... and you can get very complicated if you choose... the more likely it is you won't maintain it properly and it'll start to become a pain point for you.

    So if there is overlap in the terminology between domains then you could keep one termbase with an attribute picklist to define the domains.  But even if I did this I'd be very wary of overcomplicating the picklist.  Do too much and it really will end up being less than useful for you. You'd also have to maintain filters to ensure you get good value from all this effort when working with the termbase in Studio.

    If there is little overlap then maintaining separate termbases probably makes more sense.

    I think you also have to take into consideration who the termbases are for and how many people are going to be contributing to adding terms, what controls do you have in place to ensure your structure is managed effectively.  All comes back to complexity for me.  I'd be asking myself the question all the time... do I really need this level of complexity?  Where's the value when it's right and more importantly what are the costs when it goes wrong?

    emoji
Reply
  •  

    In the absence of a comment from anyone else... my view would be to keep it simple!  The more complex you make it... and you can get very complicated if you choose... the more likely it is you won't maintain it properly and it'll start to become a pain point for you.

    So if there is overlap in the terminology between domains then you could keep one termbase with an attribute picklist to define the domains.  But even if I did this I'd be very wary of overcomplicating the picklist.  Do too much and it really will end up being less than useful for you. You'd also have to maintain filters to ensure you get good value from all this effort when working with the termbase in Studio.

    If there is little overlap then maintaining separate termbases probably makes more sense.

    I think you also have to take into consideration who the termbases are for and how many people are going to be contributing to adding terms, what controls do you have in place to ensure your structure is managed effectively.  All comes back to complexity for me.  I'd be asking myself the question all the time... do I really need this level of complexity?  Where's the value when it's right and more importantly what are the costs when it goes wrong?

    emoji
Children
No Data