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 (now RWS AppStore) 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.
Contents
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:
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.
Add Any other translation provider…
(This is an update to this article!)
When I wrote this article last week I foolishly mentioned “Add Any Trados 2007 TM” and nothing more. The reason I say foolishly is because you add the 2007 TM provider through the “AnyTM: Add any other translation provider…” option. So when I select it I actually see this:
So it’s possible for me to use any of the Translation providers I have added to Studio in any direction and in any language I like (the “… add as a reference:” part in the window is wrong. You can update too if the provider allows it). Tremendous functionality… how I missed this the first time I wrote this I’ll never know!
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!
“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.” – eh? You have confused me with this bit … I always have multiple TMs attached to every project. So I guess you mean something else.
You’re missing the context with your question, and you might also be confusing my use of terminology. I never refer to Studio as Trados. I’m talking about the SDL Trados 2007 Translation Memory Plugin that allows this. Trados only allows one TM to be used at a time. This SDL Trados 2007 Translation Memory Plugin in Studio allows you to use multiple Trados TMs (so the *.TMW plus four other files) in a Studio project.
I then went on to say how the AnyTM plugin extends this capability even further by allowing you to have multiple Trados TMs in any language!
Make sense?
Ah, I think I get you now. Thanks for clearing that up for me. But I reckon that’s a feature that I won’t need. I upgraded all my Trados TMs to Studio a LONG time ago! 😉 And to be honest, it wasn’t such a chore. I am never likely to need the old workbench ones again. But I can see how it might be useful for some people.
Indeed… you may not have many. I know companies with tens of thousands of legacy Trados TMs across all their language pairs and for them the Trados 2007 TM Provider is an excellent application. It’s free too! The addition of AnyTM to that capability, even though there is a nominal fee for it is a no brainer I think. The value you get from this is huge, especially if you do still have customers using different flavours of Trados 2007 TMs today.
Hi Paul,
I came across this helpful blog post of yours when I was trying to solve a small problem here, but I’m not sure I have the right answer. My issue is that I want to have *one* main translation with just two source languages (German and English), as I handle projects in both directions and I find it unnerving to have two main TMs for this purpose. Does the AnyTm app help with this? I am using Studio 2011. Thanks very much, Amy
Hi Amy. Yep, this will help. You can use one TM for both directions and all flavours or English/German with AnyTM.
Hi Paul, hi dear Trados users,
I wonder which of silly concept or bad design is more efficient to spread like pest and generate fervent patching activity. No wonder the language variant is a Microsoft concept, as you confirmed in your previous post on the same subject, and indeed we must admit they are masters in that game.
Defining a new virtual language just to comply with differences in date/number/units format is insane from the start (the other reasons occasionally put forward are fluctuating characteristics and you can’t reasonably build anything rigid on them). There are just a handful of date/number/units format alternatives, yet in a world of instant global communication we get more than two hundred incompatible language variants!
System architecture at large has recognized the benefits of modularity for ages and any serious IT professional will find it obvious that date/number/units formats should be modular options on top of the language itself, as well as the few spelling differences and maybe a cultural module with hints on locally preferred terminology.
If houses were designed like Trados TMs, then you’d have to build a new one in order to have a different color for the bathroom walls.
Cheers,
Alexandre
P.S. A workaround to language variants segregation is simply to convert to TMX and replace e.g. en-US with en-GB using a simple script. You can’t keep SDLTM format for that purpose because it’s a binary black box.
Amusing… and over simplified. Interestingly it’s no more difficult to create a simple script to change an SDLTM either… it’s only sql! But there are plenty of people who do want these differences for more reasons than you have written here. There are lot’s of ways to handle this and adopting Microsoft language codes and the underlying libraries does have its virtues. Perhaps not for you… but that doesn’t mean it’s the same for everyone.
Thanks Paul for your quick answer.
I like simplicity. It’s a fault, I know. Above all it’s anti-economic. However it looks like many translators are spending more time fiddling with the shortcomings of mechanisms they don’t grasp rather than doing what they do well and are paid for, and I am not sure if this is any better in an economic point of view.
You wrote:
Interestingly it’s no more difficult to create a simple script to change an SDLTM either… it’s only sql!
Thanks for the tip! Could you tell me where I can I find such a script? It is not quite clear to me what I lose using TMX format in heavily tagged material, so it might be a safer bet if I could keep SDLTM.
Alexandre
I didn’t say there was such a thing… I just said it would be simple. You can open an SDLTM in a SQLite editor now and just change the language codes in the appropriate table. It’s faster and easier than messing with TMX. But in my opinion you would be better off working with AnyTM and then keeping the appropriate TMs for the languages they are supposed to be used for, or just use Project Templates to maintain several SDLTMs and look them all up. When you mix them together you may start seeing odd TM lookup results because recognised tokens for one language may be no longer recognised when applied to another. I think if you use Studio as your preferred tool you get more benefit from it if you bend with it rather than fight against it all the time… the latter approach just leads to more difficulties you have to overcome later on.
Of course if you don’t use it as your preferred tool then go ahead and change the codes.
Thanks Paul for this detailed explanation.
I use Trados Studio only as an interface with some of the agencies I work for, which provide and require more or less recent Trados proprietary formats. I use other tools to do the bulk of the work, except if the project is very small and the overhead disproportionate.
An ongoing project for one of the end clients changed yesterday from en-US to en-GB, with a new version containing 1000 new words only, and my numerous en-US legacy TMs for those projects became instantly unusable. Moreover Trados Studio 2011 refused to import the provided Trados 2007 TMW. So I converted my legacy en-US TMX to en-GB TMX, and now I have about 10,000 words to translate or at least double check instead of 1000 expected… No benefit, no language difference at any level, this is plain crazy. Now I don’t feel like losing my time and energy fighting with a new app which won’t be bug/issue free, especially since as you say it has been actively developed lately. So I think I will try to use SQLite hoping to get substantially more context matches. Thanks again for the tip.
Cheers,
Alexandre
If an agency sets a job and claims that there are only 1000 new words, they must at least provide the appropriate TM, especially if they are not paying for existing CMs. AnyTM is not an ideal solution, and doesn’t work (for me) during project setup, but does at least offer the benefit of not having to retranslate already translated material. If you are being paid a minimal amount for the CMs/repetitions/100% matches then you are not really losing out if AnyTM finds suitable translations for your segments. It seems to me you are complaining about something which is not really a problem with Studio. Studio has plenty of shortcomings that bug the hell out of me (which, for instance, memoQ seems to master with ease) but this isn’t really one of them.
Hello Nick,
Thanks for your answer.
You wrote :
It seems to me you are complaining about something which is not really a problem with Studio.
I am not sure what you are referring to. The absolute segregation between language variants might be seen as a feature by some, though IMHO not on a practical point of view. On the other hand, it is difficult to argue that the complete inability to import Trados 2007 TMW format into Trados Studio 2011 is a bonus.
Concerning the particular case at hand, the agency is back to EN-US: they had made a mistake at some point. Still I can’t use their TMW and they need to convert it to TMX. The significant discrepancy in fuzzy word count between Trados 2007 and Trados Studio 2011 is still a mystery but they say they won’t discuss.
Concerning MemoQ, I once tried it on a big project and it went fine. The agency could use the MemoQ,output within delays, but they wanted for their records a TM segmented along Trados rules, so I had not finished working… I never used MemoQ anymore. We are in a factual near-monopoly situation.
Yes, you’re right about the incompatibility between versions (Studio and workbench). It remains a mystery to me why SDL has never thought that users would not need to convert Trados from one format to another. I was moaning about this myself just yesterdy when trying to convert some Termbase content to Studio. Can you believe (I’m sure you can) that Multiterm does not have an export format that Studio can import? Luckily I found a useful little work around (from your friend and mine Paul Filkin) that allowed an import via CSV. But not exactly practical.
Take a look at the new Glossary Converter… it can convert from virtually anything useful to anything else… in terms of Terminology , spreadsheets and TMX files. Very clever and essential tool.
I haven’t updated yet – thanks for the tip! Glossary Converter has been the most useful tool I’ve ever used! (possibly because it’s the only one simple enough for me! haha!)