• State Suggested Answer
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 190 subscribers
  • Views 1277 views
  • Users 0 members are here
Options
Related

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

Alexander The Great

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 a file explorer window showing various .sdltb files with their sizes, such as Contracts.sdltb and EBRD gloss.sdltb.

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 a file explorer with two files named simple wo subject field.sdltb and simple wo subject field.xlsx, and two files named open.sdltb and open.xlsx with red question marks indicating potential issues.

Screenshot of an Excel spreadsheet with a column labeled 'Subject' containing various domain-specific terms such as Architecture, Civil, and Construction.

Screenshot of a term base entry interface with terms in English and Russian, categories like 'Scope' and 'Contractor', and green check marks indicating confirmed entries.

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: RWS Community AI at 6:44 PM (GMT 0) on 14 Nov 2024]
emoji
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
Parents
  • 0

    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
  • 0

    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