What's better, one big glossary/term bank or several smaller ones? Αποστολέας σε συζήτηση: Christina B.
|
|---|
Christina B.
Σουηδία
Local time: 11:13
Γαλλικά σε Γερμανικά
+ ...
Hi!
Do you use one big glossary/ termbank (per language pair?) or several smaller ones (per client, per field...)?
So far, I have been using several smaller ones but now I am thinking of just putting everything into one big file, so that I don't have to activate/ add to several different files while and after translating.
Does that sound like a stupid idea?
| | | | Catarina Lopes 
Πορτογαλία
Local time: 10:13
Μέλος από 2013
Αγγλικά σε Πορτογαλικά
+ ...
| Interesting question! | Apr 28, 2016 |
Good question, Christina. I also use several glossary files and often wonder if it would work better if I merged them into a single Termbase (in Studio).
Let's hear what others recommend
| | | | neilmac
Ισπανία
Local time: 11:13
Ισπανικά σε Αγγλικά
+ ...
I don't really use one or the other. In fact, I'm not even sure if glossary and term bank are the same thing or not. The resource I use most often for terminology is Google.
PS: Now I see others' comments I understand the query better. But I still don't really use glossaries or termbases much. I keep a basic TM for each client and when in doubt about about previously used terms or new ones, I consult the client (for example yesterday I asked them to confirm whether they wanted to ... See more I don't really use one or the other. In fact, I'm not even sure if glossary and term bank are the same thing or not. The resource I use most often for terminology is Google.
PS: Now I see others' comments I understand the query better. But I still don't really use glossaries or termbases much. I keep a basic TM for each client and when in doubt about about previously used terms or new ones, I consult the client (for example yesterday I asked them to confirm whether they wanted to use "vendor" or "supplier", as the former term is apparently gaining ground in the US (although I cant help thinking of peanut or ice-cream street sellers when I hear it)). It only usually occurs with two of them.
[Edited at 2016-04-29 10:15 GMT] ▲ Collapse
| | | | | One big glossary for me | Apr 28, 2016 |
Back in the days of Workbench, I was happy if Multiterm worked at all.
It was possible to use two TMs at a time, but I think only one Multiterm glossary, so that was that.
I had one termbase for 'everything' and one for food, as I did a lot of menus and food-industry work for a period. The two fields rarely overlapped as far as the termbases were concerned.
In recent years SDL has really got its act together, and Studio is MUCH more stable, but I still use my big ... See more Back in the days of Workbench, I was happy if Multiterm worked at all.
It was possible to use two TMs at a time, but I think only one Multiterm glossary, so that was that.
I had one termbase for 'everything' and one for food, as I did a lot of menus and food-industry work for a period. The two fields rarely overlapped as far as the termbases were concerned.
In recent years SDL has really got its act together, and Studio is MUCH more stable, but I still use my big Multiterm, with all the additions that have accumulated in the meantime.
I have a couple of client-generated special termbases, but even when I use those, I tend to couple my own in as the default and add terms to it as I see fit. They are not always exclusively relevant to that client anyway.
Updates to the client databases have to be sent as suggestions in Excel files and approved before they can be added officially to their database, so there is no point in adding terms as I translate, which I do with my own database.
I did try starting separate subject databases, but found I was duplicating a lot of entries in them, so before they got too large, I amalgamated them into a big general database in the Studio format.
I have one other project, which so far is still a table in a Word file, not a database, and I would/will keep that separate. (It fills some 150 pages and I only use it occasionally.)
I don't use the food database any more, but would probably amalgamate it in the big one if I started working in that field again.
That is my experience: I am rather a generalist. I expect it depends how one works and what fields and volumes of terminology you work with as well. ▲ Collapse
| | |
|
|
|
It depends on how you use your term bases. For example, I have a half-time position for one employer, and there I debated setting up multiple term bases but ultimately decided to make one.
For my freelance work, I have several because certain clients prefer certain terms while my personal preference or those of another client might differ. Then I just activate the ones relevant for the client.
| | | |
Kelly Neudorfer wrote:
(...) I have several because certain clients prefer certain terms while my personal preference or those of another client might differ. Then I just activate the ones relevant for the client.
| | | | B D Finch
Γαλλία
Local time: 11:13
Γαλλικά σε Αγγλικά
+ ...
| By topic/field | Apr 28, 2016 |
I prefer to have lots of glossaries in Wordfast Pro, divided by field and use the comment field to note if a particular file prefers a particular translation. That seems the best way to cut down on how many irrelevant choices I get offered while translating. Also, if I really disagree with using a client's past choice of term in a new context, then the glossary reminds me of that and I can always insert a translator's note to explain the translation I've used.
| | | | | I am just dividing mine up | Apr 28, 2016 |
It depends on clients and projects. As I created terms for some otherwise common words for several clients these tend to come up when not needed so I created separate glossaries.
Same for TM, I have one big TM and then some smaller ones.
[Edited at 2016-04-28 13:13 GMT]
| | |
|
|
|
Graeme Walle (X)
Φινλανδία
Local time: 12:13
Φιλανδικά σε Αγγλικά
+ ...
| Similar Approach | Apr 28, 2016 |
B D Finch wrote:
I prefer to have lots of glossaries in Wordfast Pro, divided by field and use the comment field to note if a particular file prefers a particular translation. That seems the best way to cut down on how many irrelevant choices I get offered while translating. Also, if I really disagree with using a client's past choice of term in a new context, then the glossary reminds me of that and I can always insert a translator's note to explain the translation I've used.
I have a similar approach using Wordfast Pro. I also have separate glossaries for specific clients who have specified that certain target term variants must be used. I can see at a glance which is the right one to use from the pop-up notes Wordfast Pro gives when it highlights a certain term in the source text.
| | | | Parrot
Ισπανία
Local time: 11:13
Ισπανικά σε Αγγλικά
+ ...
| I use smaller ones | Apr 28, 2016 |
... if anything, for confidentiality.
It's too easy to graft one client's terminology into another's. And when you specialize, they tend to be competitors of some sort.
| | | | Selcuk Akyuz
Τουρκία
Local time: 13:13
Αγγλικά σε Τουρκικά
+ ...
| I use Déjà Vu X3 | Apr 28, 2016 |
One Big Papa approach is fine for me as I use Déjà Vu X3. Client and Subject metadata are added automatically to the terms so I can use only appropriate terms. The same applies for my TM, only one Big Mama (TM).
| | | | Balasubramaniam L.
Ινδία
Local time: 15:43
Μέλος από 2006
Αγγλικά σε Χίντι
+ ...
SITE LOCALIZER
I keep different TMs for different clients, but I also have one or two largish subject-wise TMs. So while translating, I would add the client's TM and also one or two subject TMs that are relevant to the translation.
I assign highest priority to the client's TM. This way I can use client specific terminology and also derive the benefits of getting more hits from previous translations.
I follow the same approach with glossaries.
| | |
|
|
|
| A combination of both | Apr 30, 2016 |
When it comes to glossaries, basically my approach is to have one big glossary for the terms I have researched myself (and I would regret to have to research again), with clear definitions, context, and metadata to help classify the term and use it properly; on top of this, a number of individual customer-specific glossaries that basically help ensure that the customers' preferred terminology is used, independently of my researched terms.
As for memories, some translators use one bi... See more When it comes to glossaries, basically my approach is to have one big glossary for the terms I have researched myself (and I would regret to have to research again), with clear definitions, context, and metadata to help classify the term and use it properly; on top of this, a number of individual customer-specific glossaries that basically help ensure that the customers' preferred terminology is used, independently of my researched terms.
As for memories, some translators use one big mega-memory, but this brings about several issues, if you ask me:
- CAT tools are not always fond of big memories: maintenance edits are much slower, and sometimes also lookup times are slower. In some tools, there is a higher risk of corruption of a big memory.
- It is harder to respect customer preferences, as you have the preferred phrases and terminology of a number of customers all together in one memory.
- There is a risk of a person/product/brand name of one company landing in the translation of a competitor, which would be immediately termination of your work for both customers if the issue is discovered.
Personally I prefer to keep fully separate memories for each combination of agency+end customer, although I have often considered to have one additional combined memory as a help for certain genres, like contracts, EU Declarations of Conformity, certificates... ▲ Collapse
| | | | CafeTran Training (X)
Ολλανδία
Local time: 11:13
| Active Glossary, Background Glossary, Client Glossary | May 1, 2016 |
Christina Baier wrote:
Do you use one big glossary/ termbank (per language pair?) or several smaller ones (per client, per field...)?
In CafeTran I have an Active Glossary (AG.txt), a Background Glossary (BG.txt) and sometimes a Client Glossary (CG.txt).
Client glossaries are fed with Excel (CafeTran opens them directly) and (exported) Multiterm glossaries from my clients. But I seldom receive them (which is fine by my, since I can then use my own preferred terms). These glossaries are also used for CafeTran's terminology consistency check (QA). CG.txt has the highest priority and is case insensitive.
New terms are added on the fly to my Active Glossary (case-sensitive). I regularly dump the content of this glossary into my:
Background Glossary (case-sensitive, read-only), where it is merged (newest target terms at first position) with existing term pairs.
So I'm constantly optimising my BG for my own purposes. Both via periodical merging (e.g. once every month) and on the fly during translation projects (CafeTran stores glossaries in plain text files that I can very quickly edit in a text editor, e.g. to make global modifications when I've learned a better translation or when the spelling has changed).
When I'm translating files that have been translated by colleagues previously, I use CafeTran's term stack feature to have the target term that the colleague used, auto-assembled in the current project (context menu, left-click on the preferred target term to give it the highest priority).
If I don't agree with the target term that my colleague used (e.g. because it has a typo or old spelling), CafeTran's Find and Replace dialogue box will allow me to correct the target term in the TM, the project and the glossary. Modifications to the TM and translation project are made in one run (case is automatically adapted) and the modification of the glossary requires an extra run. All this during the translating process.
Glossary searches can be fuzzy (via Hunspell), but when I really need fuzziness, I use Fragment Memories in TMX format instead of glossaries. CafeTran supports them too, as another (and equivalent) terminology storage format. Here I can use attributes/properties (e.g. client, subject field) too.
Sometimes it's not possible to always have the correct target term auto-assembled, no matter how specific you define the subject field etc. This applies to generic words with multiple (equivalent) translations. In these cases I connect the target terms to related words (e.g. verbs) that can occur in the source sentences. So if verb B appears, translation C will be chosen for source term A. (If B' appears, target term C' will be used instead.)
| | | |
I have client-specific glossaries, field-specific glossaries and 2 main/huge glossaries.
I configure the search so that it looks in the glossaries in order until it gets a hit so client > field > main.
One of my main glossaries is the the huge IATE one you can download for free, even though it's more FrFr than FrCa, it's great when you have the term on the tip of your tongue though, because of its size it throws TONS of false positives so you can't rely on it the way yo... See more I have client-specific glossaries, field-specific glossaries and 2 main/huge glossaries.
I configure the search so that it looks in the glossaries in order until it gets a hit so client > field > main.
One of my main glossaries is the the huge IATE one you can download for free, even though it's more FrFr than FrCa, it's great when you have the term on the tip of your tongue though, because of its size it throws TONS of false positives so you can't rely on it the way you can on a client or field-specific personally curated glossary.
Client-specific ones are the best/most valuable, especially if the same person/people often write the source texts, they'll have specific turns of phrase that pop up all the time and you can save those - I sometimes have segments that are over 10 words long in my glossaries because they invariably pop up verbatim. Saves a ton of typing time, reduces typos & increases consistency throughout the text. ▲ Collapse
| | | | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » What's better, one big glossary/term bank or several smaller ones? | Anycount & Translation Office 3000 | Translation Office 3000
Translation Office 3000 is an advanced accounting tool for freelance translators and small agencies. TO3000 easily and seamlessly integrates with the business life of professional freelance translators.
More info » |
| | TM-Town | Manage your TMs and Terms ... and boost your translation business
Are you ready for something fresh in the industry? TM-Town is a unique new site for you -- the freelance translator -- to store, manage and share translation memories (TMs) and glossaries...and potentially meet new clients on the basis of your prior work.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
Translation news
