Recording Translation Memory metadata

Back in July 2013 I wrote an article called “Fields and Attributes in Studio” which was all about adding different types of metadata to your Translation Units every time you confirmed a segment to make it easier, or more complex depending on what you’ve done, to manage your Translation Memories.  If you’re not sure what I mean by this take a look at the article as I won’t repeat a lot of that here… at least I’ll try not to!  This capability in Studio is probably quite familiar to most users of the old SDL Trados 2007 and earlier, and was even essential to some extent because you could only use a single Translation Memory at a time.

The same features were also available in SDLX, which was the lesser known but in many ways more functional product, that was provided by SDL prior to bringing Trados into their portfolio.  In fact over the years it’s proven much harder to replace SDLX in some environments, but today I think it’s safe to say Studio is working in ways to satisfy even the most hardened SDLX and Trados user… yes, I know you’ll still find die hards out there but I do believe the capabilities of Studio far outweigh those of these legacy applications.  Not all of the features are out of the box, but a big advantage Studio has is the OpenExchange which provides a platform for developers to add their own features into Studio and this often fills a few gaps in addition to introducing many innovative and exciting capabilities.

A good example of this is related to TM metadata.  So in the screenshot below you see one segment in the SDLX editor, with a 100% match from the TM underneath it, and then metadata that is recorded by the system every time you save a segment to the Translation Memory (this is also configurable, I just put these views together for the screenshot):

If I handle the very same file in Studio then the system metadata is as follows:

Very similar aren’t they, but there are a few noticeable differences:

• Context : SDLX recognises the filetype as TEXT, as the source was a simple txt file, and it stamps the TU with TEXT.  Not terribly useful in this context, but I believe it can be useful when handling HTML/XML files where the context is taken automatically from the elements.
• TM : SDLX provides the full path to the TM used as opposed to the name of the TM only which is used by Studio.  I can see how this could be very useful, especially when trying to see why results are missing from your TMs as you can tell immediately if you have duplicate names in different locations.
• Source File : SDLX stamps the TU with the full path and filename of the file you are translating.  This could be very useful if you wanted to remove some of the TUs that were stored in your TM when just one or two of the translated files were wrong for example, or even if you just wanted to be able to analyse exactly where your translations had been used in the past.

Of these it’s the last one “Source File” that I have seen people asking for since adopting Studio.  Now if you read “Fields and Attributes in Studio” you’d know that you could easily create a Field for “Source File” and you could manually add the path to the file when you translate it like this:

Now you can see the full path and filename stamped onto the TU as a custom field whenever you confirm the segment.  This is great if you only have a few files and if you always remember to change the value of the field whenever you open a different file for translation.  But if you have a project with hundreds of small files that you open in a virtual merge for example, then the practical aspects of having to copy the path of the source file to your clipboard, and then manually go into the Project Settings and paste to update the “Update” value every time you translate a different file start to kick in.  If it was me I’m sure I’d forget to do this within the same project never mind over a period of time working with multiple projects.  I imagine it would be even worse if you were reviewing the files.  So pretty soon my great idea of using custom fields to replace the SDLX system field approach doesn’t look so good.  Yes you can do it… but it’s not so practical for this application.

Fortunately we do have the OpenExchange and help is at hand by using the RecordSourceTU application which is a free plugin developed by the SDL Community Developers to resolve this problem.  Even more fortunately the OpenExchange developers rarely do things by halves so this is what we get:

You have the opportunity to have the following, one, two or/and three options automatically supplying information to every segment you send to your translation memory:

1. Record source filename
2. Record source file complete path
3. Record source project name

The second option would mirror SDLX.  The other two are enhancements, and quite useful because they probably cover the most likely needs based on the files and projects you work on.  If I use these by allowing the app to create new fields for each of these items then my segment would record the data as follows:

But it will do this automatically for every Project and every file I work on from now on… if I’m using this TM.  Pretty cool… and I think this is cool not just because of what it’s doing, but because of what the developer was able to do without having to wait for this to be added into the product.  Even cooler is that the source code is opensource so if you liked this idea but wanted to have additional, or just different dynamic metadata stamped to your TUs without you having to manually control it then most of the work is already done for you.  That’s pretty cool!

But that’s not all of course.  If you’d read the original article and decided to create a field for these things yourself and are now happily using them with the manual update route, then this is also catered nicely for.  In my earlier example I created a field and called it “Source File” which is different to the automatically created one.  So if I wanted to use this application with my existing TM I just select that field like this:

Now the existing field would be automatically updated and I won’t have to add the new filename into the update field every time I move onto a new file.  Very helpful feature.

Now the one thing I didn’t mention is how do you invoke this solution in the first place?  Well, this is also fairly simple as the app is basically a new TM provider.  So first you download the RecordSourceTU application from the OpenExchange and install it.  Then restart Studio and when you add your TM to your Project you do it with this option:

It works the same way as AnyTM, you would select RecordSourceTU and then pick the TM you want.  This will immediately present you with the window of options so you can confirm which metadata you would like to see added to your TUs as you work.  Simple.  If you want to change the options at any time you just go back to your list of TMs and will see that the RecordSourceTU TM is also conveniently annotated so you can see which one it was, and click on Settings and then OK:

This will invoke the options again and you can change them as required.  Please note that once you have been using fields created or maintained with this application that the rules and restrictions associated with these features are the same as they were in the original article.

But still a great feature and timesaver if you wish to be able to store this additional useful information without even having to think about it as you work!