In February last year I wrote an article called “It’s all English… right?“. It was about a Translation Provider plugin available through the SDL OpenExchange and it resolved a common request from users. The request was why can’t I use my en(US) Translation Memory with my new customer who wants the work as en(GB)?
It’s a valid question, and Studio does have valid reasons for wanting to retain the differences between the different flavours of English… or any other language you work with that also has different flavours, like Spanish, French or Arabic for example. But it’s also a valid request to be able to use one Translation Memory for this because it’s perfectly simple for you, as a Translator, to maintain multiple Translation Units and handle any other differences between placeables that Studio assigns automatically based on the language flavour.
So why am I writing about this application again? Well quite simply because in the last 12-months since this application was first released the developer, CodingBreeze, has introduced a number of improvements that really justify a new visit to look at this again.
Bi-directional Translation Memories
I’ll start off by addressing one of the latest additions to this application as this is probably the most commonly requested question around the use of Translation Memories in Trados and Studio alike.
If you translate English to Hebrew for example (I’m at the Israeli Translators Association annual event in Herzliya where the AnyTM application was of much interest… hence the risky decision to use Hebrew!), and also Hebrew to English, then traditionally this meant you have to maintain two translation memories… at least two if we discount the different flavours of English but as we know this could be as many as 32 if you happened to have clients using all the different flavours of English! The new version of AnyTM will maintain a reverse Translation Memory for you so that as you work you are automatically storing the translations into a Translation Memory working in the other direction. You only need to select the same Translation Memory through the AnyTM provider irrespective of the direction you work.
It works like this… I translate this simple file from Hebrew to English (the Hebrew text was obtained roughly!!!) using a Hebrew to English TM:
I save this target document so I have an English version of the same text. Now I open the English target document in Studio as an English to Hebrew translation and select the same Hebrew to English Translation Memory I used before, but I do this by selecting the AnyTM provider like this:
This action does two things:
- If this is the first time I have done this it creates a reverse Translation Memory in the background so now I have two:
![05]()
The second one is created using the same name with .anytmreverse added to it. - It updates itself with the contents of the original Hebrew to English Translation Memory but in the opposite direction.
So in my Translation Results window I am now getting matches for this document despite the fact that I have never translated the file in this direction before:
In future I just select the Hebrew to English Translation Memory for all my Hebrew to English and English to Hebrew Translations and no longer need to update them separately using an export/import process to keep them in synch. Pretty nice!
Add any Language TM
This is not an update to the current version, but it is an update the original article I wrote in February last year. Previously it was only possible to add a Translation Memory with the same main languages. So you could use an en(GB) Translation Memory for a Project based on en(US) for example. But now you can add any languages whatsoever… so you could use a German to French Translation Memory with a Hebrew to Arabic Project! Of course this would be of little value in practice but it might be helpful to use an English to Dutch with an English to German Project to help with a little inspiration, especially if you knew you have translated something similar before and you are gifted with this kind of fluency.
Multilingual Source
A really interesting enhancement to this updated release is the ability to recognise the languages being used automatically, or by manual selection. What’s so special about this you may ask? Well the doesn’t just do it at a document or Project level… it does it at segment level. So you could have a single document containing several languages and translate them altogether in the same file. So there are options available through a new menu item in the Advanced Tab of the Editor View:
If I activate this and check the box to tell Studio that this Project has content in more than one source then it can detect which languages are being used. The languages set for the Project were en(US) – fr(FR), but this is irrelevant using this process:
Now, it doesn’t always get the autodetect correct, and in this case you can see it suggested Afrikaans for Dutch… but I did use Google Translate to get the Dutch translation in the first place so perhaps this is at play here! However, I can correct this manually.
To test this I also added three Translation Memories to my Project for this multilingual source file using the AnyTM provider, one for each language pair. I enabled them all and set them all to update:
I can now start translating the file, all going into French. As I do this the appropriate Translation Memory is used to update the work based on the recognition, and if you watch the new window you can see the source language changing as you work through the translation. As I played with this one it got the Hebrew 100% correct, and the English 100%, but the Dutch was only recognised one out of three. So in practice I think it pays to keep the new window open so you can manually correct which source language is being used and make sure the TM being updated is the right one.
Pretty clever though and I was able to work with three completely different Translation Memories and update the right one for each segment, all in the same file.
I think even if you don’t use the Autodetect capability and use the manual option, having the ability to select the TM to be used so easily as you work is a great time saver if you receive files of this nature and want to be able to capture all of your work into your Translation Memories without having to create several Projects and translate the file three times, avoiding the languages you have already worked on as you go.
Add Any Trados 2007 TM
There is another application on the OpenExchange called the SDL Trados 2007 Translation Memory Plugin that allows you to connect directly to the old Trados TMW Translation Memories and use them for lookup and concordance in Studio. This is great as it can save a lot of work in upgrading, particularly with very large TMs, or if you have a lot of them. The additional advantage of course is that in Trados you cannot have multiple Translation Memories attached to a Project at the same time. So using this plugin allows you to have multiple legacy Trados Translation Memories attached as you work with Studio.
This AnyTM release takes this whole concept a little further and now you can have the same benefits I have mentioned already by being able to use these old Trados legacy Translation Memories irrespective of the language pair in the Project. This is really useful because it increases your ability to leverage the resources you already have.
Add AnyServerTM
Since the release of the original AnyTM plugin the developer has also added the ability to use any Translation Memory from SDL GroupShare. This is the new version of TM Server and MultiTerm Server that is a single web-based facility for managing Translation Memories, Termbases and Projects on a server. So it’s sort of like Studio on a shared Server but with more features for managing workflow, assigning work and many other interesting things around collaborative working.
The end…
As I’m reading through this before publishing I’m incredibly impressed by how much functionality the developer has put into this plugin, especially with regard to it’s ability to solve questions we have seen for years and not been able to provide a really simple solution for. I hope this article has explained reasonably well how much this application has evolved from the original AnyTM plugin created a year ago… and maybe even helps justify why I called this a SuperTM!
