Pages in topic:   < [1 2]
I'm new - question about TM
Thread poster: Hilde Vermee (X)
Tomás Cano Binder, BA, CT
Tomás Cano Binder, BA, CT  Identity Verified
Spain
Local time: 08:06
Member (2005)
English to Spanish
+ ...
One single memory... only if your work environment allows it Sep 8, 2008

Kevin Lossner wrote:
If you use the attributes properly, that's not an issue. For example, I indicate agency, end customer and subject area. If/when I see a match I can decide what to do about it. Mostly the content shows up in concordance searches for specific terms anyway, where non-disclosure is barely relevant if at all.


I can see what you mean. We have tried this several times in the past, and the result was always the same: as we work for approximately 5-7 different customers and in some 10-12 different jobs a day, we sometimes ended up with TUs for Spud-you-like Inc. as part of the TUs of Spud-of-your-dreams, Inc., which is not acceptable.

If you change jobs very frequently during the day, it's easy to use incorrect attributes and contaminate your memory. So my advice is: use one single memory only if your daily work does not mean a frequent change of end customer or agency.


 
Viktoria Gimbe
Viktoria Gimbe  Identity Verified
Canada
Local time: 02:06
English to French
+ ...
I second that - no boos and hisses from me Sep 8, 2008

Kevin Lossner wrote:

Another recommendation - which will probably incur boos and hisses - is to learn how to use MultiTerm (a lot of people HATE it). Use it both as an aid to translation and a tool for quality control of mandatory terminology.


I use MultiTerm increasingly, and although I find the interface anything but user-friendly (you thought Workbench and TagEditor were user-unfriendly? try MultiTerm!), it is a very useful tool. You need to fiddle with it a lot to learn to use it, but when you do, you will find it adds a useful layer to quality control, and it, too, can help you work faster.

To those who have tried using MultiTerm with little or no success, and to those who gave up on it already, here is a useful link to a free course on using MultiTerm: http://ecolotrain.uni-saarland.de/index.php?id=1750&L=1

Also, here is the link to the exercises for the above course: http://ecolotrain.uni-saarland.de/index.php?id=1678&L=1

It is since I read and put into practice the above exercises that I finally understood how I can import and export termbases, and this is also how I learned to turn an Excel or tab-delimited file into a termbase.

Also, download the free ApSic XBench. It will let you create a project containing project-specific TMs, termbases, bilingual files (compatible with all the stuff you create using the SDL Trados suite). I will not get into more detail here, but look it up, install it, fiddle with it, and you'll see.

For now, I would recommend you to learn to use text fields (or attributes - I find this term more fitting than text fields, by the way) and to learn to create, use, export, merge TMs. Then, I think you should learn to use MultiTerm - the links above will teach you pretty much all you need to know for normal freelance use. Then, practice a bit using both your TMs and your termbases until you feel you are at ease with the technology. Then, once you have a firm grasp of the concepts of TM and termbase and their use, explore XBench.

All the best!


 
Amal Ibrahim
Amal Ibrahim  Identity Verified
Germany
English to Arabic
TM naming convention Sep 8, 2008

Viktoria Gimbe wrote:

One last thing: figure out a TM naming convention. You will see that as you create new TMs, you will get to a point where you will have dozens, or even hundreds, and if you don't have a sound naming convention for them, you can easily mistake one for the other.


What would be a sound TM naming convention?
Thank you!



[Edited at 2008-09-08 23:37]


 
Viktoria Gimbe
Viktoria Gimbe  Identity Verified
Canada
Local time: 02:06
English to French
+ ...
Naming conventions Sep 9, 2008

Naming conventions depend on how you sort your TMs. If you create separate TMs for each client, it makes sense to start the name by the client's name. I start the name of my TMs by the client's name. But since I create TMs per project, I also add a short version of the project title. My naming convention is:

[Client name] - [Project name] - [version]

I separate each element of the name by a dash, for clarity.

The version part of the name is very useful. Som
... See more
Naming conventions depend on how you sort your TMs. If you create separate TMs for each client, it makes sense to start the name by the client's name. I start the name of my TMs by the client's name. But since I create TMs per project, I also add a short version of the project title. My naming convention is:

[Client name] - [Project name] - [version]

I separate each element of the name by a dash, for clarity.

The version part of the name is very useful. Sometimes, you use a TM for a client, and they eventually come back to you six months later asking you to translate something for the same end client. It then makes sense to use the same TM. However, the client gives you an updated version of the TM (other translators have used the TM in the meantime, modifying it and adding to it). This often means that an otherwise useful and correct TU may have been edited to something worse. By keeping the old version of the TM, you still have access to older TUs (a bit like an archive). But you also need to be able to distinguish between versions. So, I add version info at the end of the file name. Usually, this is a date.

A typical TM filename for me is:

Client XYZ - XYZ Impact study - August 2008.tmw

If you organize TMs by subject, then you can adapt this model and use the subject as the first part of the TM name. In this case, I would still keep TMs separate per client, so the TM name would be something like this:

Environment - Client XYZ - August 2008.tmw

The beauty of attributes or text fields is that you can, depending on the work at hand, create a TM from scratch and import several of your TMs into it. Then, you can use that as a reference TM and use the main TM the client wants you to use as your active TM. Since you used text fields, even if you merged different TMs into your reference TM, you will be able to tell which individual TM the match proposed by Trados belongs to (the information is displayed at the bottom of the Workbench window).

This allows you to create project- or job-specific TMs that are customized to your personal needs, while you are still keeping your individual TMs separated. Once you are done with the translation, just delete the reference TM you created earlier (it's only a copy of the individual TMs in your TM library, so you still have the "originals").

[Edited at 2008-09-09 01:50]
Collapse


 
Amal Ibrahim
Amal Ibrahim  Identity Verified
Germany
English to Arabic
Naming conventions Oct 5, 2008

Viktoria Gimbe wrote:
A typical TM filename for me is:
Client XYZ - XYZ Impact study - August 2008.tmw


I finally managed to organize my TMs in a very effective way, but I find it rather difficult to remember the language direction of each TM. How do you that?

Do you also have a naming convention for your termbases? Do you create a termbase for every TM?

Thank you!


 
Vito Smolej
Vito Smolej
Germany
Local time: 08:06
Member (2004)
English to Slovenian
+ ...
SITE LOCALIZER
Use prefixes Oct 5, 2008

I finally managed to organize my TMs in a very effective way, but I find it rather difficult to remember the language direction of each TM. How do you that?

I prefix my TM names with the language pair, like DE SL Aardwark.*
Do you also have a naming convention for your termbases? Do you create a termbase for every TM?

Terminology has more to do with the field than with any particular project or client. Carburator is carburator and stays one, whatever the car producer and the model of the car. So for this particular field you would for instance name it "EN DE FR mechanical engineering"

Regarding the number of TMs - it 's a compromise: having too many complicates the coordination / synchronization of standard translations and terminologies: diffusion effects kick in. Having too little of them on the other hand is not safe (a lot more china can get broken if anything happens) and additionally makes it difficult to keep the customers separate. Using fields and attributes is fine, as long as your fingers are slower than your mind - I bet everybody here experienced cases where it was necessary to backpaddle because some project field was wrong or missing.

My trick: as a backdrop for all other TMs I have one catch-them-all mother-of-them-all TM, called XX YY - Full Monty (XX YY for the language pair), where everything gets dumped in - addition to the specialized TM used -. While the quality of this catch-all TM is dismal, it's excellent place to go fishing for some half-forgotten, faintly familiar segments.

Regards

Vito

[Edited at 2008-10-05 15:32]


 
Amal Ibrahim
Amal Ibrahim  Identity Verified
Germany
English to Arabic
Thank you for the useful tip Oct 7, 2008

Vito Smolej wrote:
I prefix my TM names with the language pair, like DE SL Aardwark.*


Vito Smolej wrote:
Regarding the number of TMs - it 's a compromise: having too many complicates the coordination / synchronization of standard translations and terminologies: diffusion effects kick in. Having too little of them on the other hand is not safe (a lot more china can get broken if anything happens) and additionally makes it difficult to keep the customers separate.


It makes sense, but I have a rather different workflow. I create a TM for each project, translate in WB, clean, proofread, edit and then align the final version and export it to a new TM. I find it difficult to edit my translation in Trados. I used to clean and edit in Word, and never had the time to update my TM. I never tried a reference memory in WB. I have all my TMs exported for reference in XBench. Perhaps there is a better way..

Regards


 
Pages in topic:   < [1 2]


To report site rules violations or get help, contact a site moderator:


You can also contact site staff by submitting a support request »

I'm new - question about TM







CafeTran Espresso
You've never met a CAT tool this clever!

Translate faster & easier, using a sophisticated CAT tool built by a translator / developer. Accept jobs from clients who use Trados, MemoQ, Wordfast & major CAT tools. Download and start using CafeTran Espresso -- for free

Buy now! »
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 »