If you were a user of SDL Trados 2007 or earlier you will probably be familiar with the concept of “Fields and Attributes”… if you are a new user to this kind of technology then you may not be. But in both cases I hope this article will provide a little bit of useful information on how they are used in Studio.
I used a picture on the left of a filing system because this is how I see them. They are simply a way to organise the translation units that are saved into a Translation Memory so that you can easily find them as your Translation Memory grows and your biological memory fails 😉
In the olden days of SDL Trados 2007 and earlier these were a necessary requirement if you wanted to avoid having separate Translation Memories for each client. This is because the old technology could only use one Translation Memory at a time… in Studio of course this is not a problem because you can add as many Translation Memories as you like to a Project. So in the past users would typically create “Fields and Attributes” relating to things like Client Name, Project Number or Topic. They would then update their Translation Memory with the values for these things as they worked on a particular translation and this made it possible to do things like export a Translation Memory consisting only of Translation Units for one specific client for example. This same principle can still be used today in Studio and you would do this in the Fields and Settings for your Translation Memory.
To try and explain this a bit better I set up a filing system based on me translating about dogs… Terriers in fact as these are my favourite breed. So I have several clients, each one gives me work based on a project code that changes each time, I like to be able to ensure the relevance of the memories by breed and I also share work from time to time with other translators. Last but not least, even though I could use the created date to ensure I got my recent translations first I also like to save them by year. So my filing system might look a little like this:
I could have drawn this a number of ways, but it’s actually quite tricky to reflect something like this usefully in a physical filing system because in order to be able to select all the work done for a particular client in a particular year, by a specific translator and about a particular type of Terrier I’d have to be very diligent about filing things away and organising my work carefully. It’s no different when you do it virtually in a computer, you still need to have an idea about how you want to organise your filing and how you might wish to retrieve the information in the future. But the computer can help you considerably with the relationships between the different “Fields and Attributes”.
So how do I reflect this in Studio? Well here’s one I created earlier… as a child I was a Blue Peter fan and if anyone can remember Shep you’ll know how long ago that was 😉 You can find this dialogue by right-clicking on Translation Memory in the Translation Memories View, select Settings and then click on the Fields and Settings node:
There are four headings across the top: Name, Type, Picklist and Allow Multiple Values. The Type column refers to the type of field, and this can be one of the following:
- Text : This is a free text field allowing you to add whatever you like whenever you update a translation. I’m using this for my Project Codes as these could be anything and it’s easier to maintain when it changes with every job.
- Number : This would be used if you wanted only numbers to be used. So there are controls in place to prevent you entering anything that is not a 0 through to 9. I’m using this for the year the work is being done. Might be particularly useful for numeric product codes for example.
- Date/Time : Provides a calendar like approach to picking a date. I’m not using this but if I was it would be an easy way to add the time and date I was working on a translation as a field value.
- List : This provides the ability to specify one or more field values from a list. I’ve used this for my clients and specific breed of dog because these are pretty much stable fields and having them in a drop down list makes it easier for me to ensure I don’t misspell anything and have duplicates in my Translation Units.
The Attributes are the values in the Picklist column, and they are the values that I enter before I start translating for the Project, Translator and Year Fields.
I also have a column called Allow Multiple Values and using this simply allows me to have several values for the fields I checked against a single Translation Unit… hopefully this will become clear as you read on.
So, I receive some files to translate and I set up my Project in Studio (or I can do them one at a time using Open Document – single file project). Then before I translate a single word I set the update values here in my Project Settings:
Note this is my Project Settings. If I do this under Tools Options after creating the Project anything I use will have no effect at all.
The Fields that were based on Picklists will contain Attributes I can choose from a selection like this for example:
If the Allow Multiple Values was ticked when I set these up then I would also be able to select several types of Terrier too. Which I might do if the text referred to several types. The other Field values not based on Picklists are just typed in.
Now I can start to translate and when I do I see that these values are reflected in the Translation Memory View for each segment I confirm. So I now see this sort of thing where the Fields and Attributes are stored against the Translation Unit in my Translation Memory:
Where I have allowed Multiple Values to be used then these are all stored against the same Translation Unit:
IMPORTANT NOTE : You must be very careful about your choice of Allowing Multiple Values because if a Field does not have this value checked then it will overwrite the previous Translation Unit in your Translation Memory unless you Add as New Translation and this means you making the conscious decision to use Ctrl+Shift+U rather than Ctrl+Enter as you are translating and this is probably going to be something you can easily forget as you work quickly through the file.
So in this example so far the Translation Unit is saved with the latest values for Project Nr., Year and Client. This is also something I really don’t want because in order to be able to extract Translation Units for a specific Project for example I can’t overwrite this value or I will lose the ability to select a different Project Nr. I also don’t want this to be added as a new Translation Unit because I may want to extract all Translation Units for a specific Client and then not have to select every single possible value for the Project that might be associated with it. So I would go back and change the setting for the Project Nr. Field so that it allowed multiple values.
Oh oh! So realising you made a mistake in how you set up the Fields and Attributes later on could have potentially damaging effects. If you’d been working with this for years for example it would be pretty damaging to lose all the careful filing from over the years. So the lesson here is that you must be very careful in engineering your filing system at the start. And another tip would be to not get carried away with what is possible… rather keep it simple and then you are less likely to run into problems and more likely to be able to do useful things with it.
What can you do about it? Well for the rock steady Translators who don’t like to get under the hood the easiest thing to do is to create a new Field and allow multiple values. Then use this one instead going forward. When you set the update just leave the old field blank and this way it won’t be touched… so for example I can do this:
The end result is that when I want to extract by Project Nr. I now have two Fields and Attributes to choose from.
For the daring geeky types out there you can export the entire SDLTM to TMX and work a little magic with search and replace in a text editor… but I’ll leave that for another article if anyone wants to know and doesn’t know where to start!
So now what?
I’ve now written quite a bit and you may still be wondering what you would do all of this for anyway? Why not just use multiple Translation Memories? Of course, in my opinion this can be the best approach, particularly if you maintain a separate Translation Memory for each client you work for. Furthermore the ability to use a Project Translation Memory in Studio makes it really easy to have a ready made memory to hand over to your client at the end of each project. There are even more applications on the OpenExchange that make it simple to convert your bilingual files into Translation Memories, so there are many ways to handle a simple requirement without using Fields and Attributes at all. But…. if you did then here’s a few examples of what you could do…
Export part of your Translation Memory
Export to a TMX (Translation Memory eXchange file) all the work you have done since 2011 for “The Kennel Club” about all types of Bull Terriers:
Change many Fields and Attributes in one go
You could create a filter for all work completed in the last week and then use this filter to change all the Field values for your Client Field because you mistakenly used the wrong value! So like this all the values used for the Client Field in the last week will be changed to “Crufts”. You would create and save the filter first in the Translation Memories View with the Translation Memory open, and then close the Translation Memory and right-click to get the Batch Edit menu here:
Delete part of your Translation Memory in a controlled way
You imported a TM provided to you by your colleague Max and updated it against his name. You then discover that whilst the translations were all good, the material was mostly irrelevant so you didn’t want it in there any more. You need to create a filter again as before (this time based on the translator called Max and saved as a filter called Max Translations), but then you can select it here like this:
Ensure you only use relevant parts of your Translation Memory
You find that as you are translating a particular job you are getting results from your TM and from a specific Translator in 2008 that are not as relevant as the translations you know you did last week! So you can apply a penalty based on a filter so that results returned from the Translation Memory as you work will be penalised and therefore show up further down the list than the more recent ones you want:
Hopefully you get the idea? This whole area around maximising the use of your Translation Memory resources, and filing away the Translation Units in such a way that they are useful for you is a pretty big subject. But maybe this article has been of interest and given you a few ideas if you haven’t used Fields and Attributes before.
But just to finish off this rather long article I’d like to mention again the principle of keeping it simple. Don’t use these if you don’t have to or can’t see a reason based on the way you work. But if reading this article helps you to see a way to do some things you always wanted to but didn’t know how then remember… simple is best!