This application, free on the SDL OpenExchange (now RWS AppStore), has been around for about a year and a half and is one of the most popular applications on there. It was written by Patrick Hartnett and is incredibly useful in more ways than one. In fact it’s so useful I have referred to it quite often and used it for working around other issues in many of the articles I have written… so why haven’t I written specifically about it here until now? The answer is I have no idea… but I should have done! What prompted me to write now is that Patrick hasn’t released many updates to this tool, mainly because it did what was needed from the start and has been a really reliable and useful application; but he has released an update this week.
You can get a copy from here : the SDLXLIFF to Legacy Converter
The logo is quite fitting because what this application actually does is provide the ability for you to convert your files that had been prepared for a hare into ones for a tortoise 😉 So you can prepare your projects in SDL Trados Studio which gives you SDLXLIFF files, and then convert them to the following:
- Bilingual Doc(x)
- Bilingual TTX
- TMX Translation Memory
The obvious benefit of this application is that you can prepare your files in Studio, convert them to an older bilingual format (Doc(x), TTX) and send them to a translator or reviewer who is working with an older CAT technology that cannot handle SDLXLIFF. But it gets better… once you make the change in the older bilingual format you can use the Legacy Converter to update the SDLXLIFF file so you don’t have to manually apply the changes.
An important point to note however, and this often leads to confusion for some users, is that the TTX or Bilingual Doc(x) that is created is based on the SDLXLIFF. So this is a bit like running an SDLXLIFF through the old Translators Workbench…. but without the XLIFF. The file you get will clean up into an old Trados 2007 Translation Memory but the target file will be nothing more than text. It will not be the same filetype as the file that was originally used to create the SDLXLIFF. So this is really a tool, when used in this way, for enabling a workflow to get translations or reviews completed by subject matter experts who still use the older tools.
The update this week contains, amongst others, enhancements for a couple of things that users have been asking Patrick for to make this even more useful.
- Included new filter option ‘Un-locked segment’
-
Included 2 new general options related to empty target translations, as follows:
- Copy source to target for empty translations during export
-
Ignore empty translations
It was these that really prompted me to add an article about this tool because the first one makes some of the workarounds I use this tool for much easier to apply as you can now use regular expressions in Studio to find the text you want and then lock it, rather than to find the text you don’t want (which is often harder) and lock that. For example, if you wanted to calculate the analysis of a file without the numbers in Studio then you can now do this by filtering on the numbers, locking them, export all the rest to TTX and then reanalyse the TTX. Previously you would have to select everything apart from the numbers so you could export the contents of the locked segments to get an analysis of the file without numbers. This is often a harder regular expression to concoct. You can read that article here.
So you can find this new filter option for “Un-locked segments” in the filter settings here:
The second most interesting and useful enhancement was spelled out nicely at the ETUG (European Trados User Group) conference in Berlin last week by Andreas Ljungström, a trainer and consultant, who uses this application a lot for outsourced work to old tool users. In the previous version when you created a legacy bilingual file then any segments that had no match in Studio were filled with the content of the source. This meant that the translator had to first remove the target content in order to get their TM match automatically added which slowed them down quite a bit. So now the files can be prepared by automatically copying source to target for empty translations or not (during export) and/or ignoring empty translations (during export/import):
I’m sure many users of this application will be pleased to see that one!
What’s next? Patrick is working on the release of an API (Application Programming Interface) library and command line exe so that anyone using the Studio API for automation of their workflows will be able to integrate the Legacy Converter as well. In this way they will be able to use Studio to prepare all of their work in an automated way and prepare TTX or Bilingual Doc(x) files for those still using older, or different technology for translation. Keep an eye on the SDL OpenExchange (now RWS AppStore) for that one!
To finish off I thought a quick demonstration of how the application works would be best, so I created a short video that I hope will be useful for anyone wondering how this excellent application works:
Video : 8 minutes 36 seconds
I saw this but I’m puzzled. Per the above description, this does not seem to be optimal per your note.
Then after downloading this pgm and giving it a try, I noted a comment somewhere about downloading a ttx file directly from
sdl 2011 editor. I certainly had expected that to start with but did not find any reference in the help for things like ‘export ttx’.
However I noticed that under file->save target as, there is an option for tradosStag document. I have seen the name tradosStag associated with the ttx file format, and sure enough, that option saves a bilingual ttx file type. It’s seems a bit strange because I had to specify save source or save target, however save target->tradosStag document saves a ttx file. To be sure of what this is I reloaded it into sdl 2011 and was able to see the whole source and target; this appears to reload and reconstitute the same sdlxliff as the one I exported from. And I verified that from the new project I can still export the target into the base document.
So what am I missing? Why is this needed if I have SDL 2011 and SDL 2011 directly exports a full bilingual file in ttx file format? What is the diff between the file I ttx created by sdl per the above and the file created by this creature? There may be fancy extra features here, but my task was simply to return a ttx file to my client and I believe I did that correctly by exporting that from SDL and sending it. Please correct me asap if I’m wrong about that as all I was able to do was to verify that when I reopened in SDL 2011 it had all the source and target data, and could be reexported into the original word doc.
I’m not sure where to start as you seem to mixing so many things up! First of all, Studio allows you to save what you start with. So if you start by translating a TTX then you can save the finished translation as a TTX. TTX is the old bilingual format created by Trados 2007 and earlier. This means that it was created by opening another file in Trados 2007 (a doc, or an excel file, or an inx files… whatever) and saving it in TagEditor (part of the old Trados 2007 suite) to get the TTX. The reason I tell you this is because if you open a TTX in Studio then when you use Save Target As you will be given the opportunity to save the file as a TTX OR as the original file format that was used to create the TTX in TagEditor in the first place (so the doc, excel, inx or whatever). There are some rules around this being successful or not but this is the theory.
Now, this article is about taking an SDLXLIFF and converting that to TTX. You cannot use the TTX you get from this to obtain the original format, and you cannot use the TTX from this as if it would be the same as the TTX you get from using TagEditor. What you get is a doc (excel, inx, xml or whatever) converted to an SDLXLIFF converted to a TTX.
The reason this is useful is because it means you can share your translation as a TTX for anyone using tools that cannot open an SDLXLIFF and then use the edited TTX they return to you to update the SDLXLIFF.
So, if your client gave you a TTX to start with then you don’t need this tool at all. If they didn’t and they asked for a TTX back then you should really convert whatever they gave you to a TTX BEFORE you translate it. Then Studio can return the translated TTX correctly.
This application is for a different usecase that may or may not be useful for you at all. Check this article to understand this more, or maybe read this one too.
Thanks for the reply. I really appreciate the quick response!
If I’m mixed up it’s because sdl’s interfaces are confusing and very poorly documented. Eg. I tried help: ‘ttx’ and ‘export ttx’ and get nothing specific about exporting these files. Export is the generally accepted term for this kind of function in the software world, btw. The fact that you can “save target” to a ttx to get this function is super confusing. For one thing it says save in original format or save as ‘trados stag document’. How the heck was I supposed to know that ‘trados stag’ == ttx?
Some of us don’t have years of history with this stuff. It was only by accident that i saw in some discussion somebody wrote
“trados stag (.ttx)” that I first realized there was an equivalence.
The other thing that is crazy-counterintuitive about this is the function on the gui is ‘save target’, and if the I save to doc format then I get a mono-lingual .doc file. So ‘Save target’ does seem an awful lot like it should be saving a monolingual file doesn’t it? I mean that would be consistent would it not, both with the description of the function and with the behavior is in saving to a monolingual source format document?
If I wanted to save the bilingual file, I’d certainly expect ‘save as’ to be the interface to do that, but of course that only offers me the choice of saving a sdlxliff file. Why oh why did some fiend hide this function in ‘save target’ if not to deliberately confuse me? I can’t imagine what he was thinking. And why did they expect me to know that ttx is also called trados stag? What’s more, if I can export a ttx file, that seems like the sort of thing I’d look for in help doesn’t it? That’s the best English language description of the operation as far as I can tell. It’s exactly how most windows applications describe this function of outputting a file of different format than the one used by the program. But not SDL.
So yeah, I’m very mixed up by SDL. I was sent a ttx file made from a doc file by what version of sdl or what tool i know not. Let assume that they sent me a file from sdl 2009. Will they be able to use the version created by “save source” with full function?
Your remarks about this converter seems to imply that if I used the converter to convert the sdlxliff file sdl 2011 created into ttx
then some functionality might be missing (like the ability to get back to a doc file) if I return that and they try to use it in 2009.
Also this comment was on another thread and was unanswered — the poster had problems using ttx files from 2011 in 2009.
There are some strong indications that these files might not be perfectly compatible. so yes that is confusing and I spent a lot of extra time and effort trying to verify this stuff as best as I can because SDL fails to make any of it clear. Thank you very much for being quite kind and helping me figure this out!!!
this post comes from http://tur.proz.com/forum/sdl_trados_support/222638-ttx_files_in_sdl_trados_studio_2011.html
“My client sent me folders to translate with .sdlxliff files. They asked me to deliver folders with files in .ttx format. I need to use projects because the folders contain thousands of files.
I have no issues opening these folders with Trados Studio 2009 and exporting them (batch task) as .ttx files. The problem is that my freelance translator uses Trados Studio 2011.
He delivered the folders with .ttx files, and I can open them one by one in Trados Studio 2009, but when I try to open them as projects, the files open in the project editor mode for a few seconds but then close immediately and I get error messages “an error occurred whilst trying to determine the file version”.
I then can’t do anything else to try to correct the files.
Any ideas?
I don’t have Studio 2011 so I can’t play around to figure out what is going wrong.”
Crikey… you write so much!
First of all, before responding I want to make sure you realise this is my personal blog and these are my personal views. So if you don’t like the response it’s all down to me.
Export files… I don’t believe this is the accepted term for what is happening here at all. If you are working in a database you might export the files but not when you are working on flat files. If you open a word file you don’t export it. You might export it to another format to exchange information with another tool, but you save it when you’ve made changes. It’s exactly the same with SDLXLIFF. You open a file to work on it and from that point you have a number of options.
1. You can Save it – naturally this saves the SDLXLIFF as this is the file you are working on.
2. You can Save As – naturally this allows you to save it with a new name, the same as any software
3. You can Save Source As, or Save Target As – this allows you to save the bilingual file (SDLXLIFF) you are working on as the original file format. Either containing the source text, or the target text.
There is nothing difficult or abnormal about this in my opinion. Perhaps the problem is just that you are unfamiliar with these concepts.
TTX is just a file format… it’s been around for a very long time. It became the “standard”, along with Bilingual DOC, for bilingual file interchange in this industry. So if you don’t know this it can only be because you are unfamiliar with the industry and with the different bilingual filetypes that get used. Out of curiosity I searched for TTX in the online help. The first hit is this:
Studio 2014 migration guide
– seems sensible as this is a legacy format. In this guide there are 142 references to TTX. You only need to read a little and you’ll find all you ever needed to know about TTX.
In the search options for the Product help you can also search the Knowledgebase (if you didn’t know where it is… and it is linked from the Help ribbon in Studio). Search the KB from here returns a further 145 results for TTX… don’t think I need to say more.
But I will… if you do go to the Knowledgebase there is a number of tabs across the top and one of these says GLOSSARY. In there under TTX you also get to find out what it is.
The way I look at this is if I was new to an industry how would I know anything without looking a bit better than you have so far. I wouldn’t know that a MIF file is for Adode Framemaker, or that INX, IDML and INDD are all forms of Adode InDesign, or that Quark Express files for translation are XTG and TAG files? In fact I might not even know that an MDB could be a Microsoft Access file!
So let’s just add something here to answer your next point.
Bilingual Files
TTX – created by Trados 2007 and earlier
SDLXLIFF – created by Studio 2009 and above
Translation Memories
TMW (plus four index files) – created by Trados 2007 and earlier
SDLTM – created by Studio 2009 and above
The interesting thing here, perhaps, is that you can Save all of these files. But, the Translation Memories are basically existing in a database, so these can also be exported as exchange files to share with others. I think this is a much more appropriate use of the term export than the way you use it.
TMX – XML format with no fixed standard used by pretty much every CAT on the market. So different tools can export TMX files that should be good for exchanging the Translation Units inside, but not necessarily other information such as fields and attributes, or unique IDs for example.
TXT – text format used by Trados 2007 and earlier
With regard to my comments on the Legacy Converter. Of course you won’t be able to get back to the original DOC file used to create the TTX. As I said, this tool creates a TTX from the SDLXLIFF. So it rewrites information in the SDLXLIFF, information that is already segmented and handled in a completely different way to TTX, and creates a simple TTX file segmented in the same way as the SDLXLIFF. This has many uses… but the usecase you want is not one of them. The way to handle your usecase, as I have explained already and it’s in the articles I referred you to is this:
1. Create the TTX using Trados 2007 or SDL LegIt!
2. Translate the TTX in Studio. So you are converting the TTX to an SDLXLIFF now.
3. Save the target file as a TTX when you’re done from Studio (no need to convert it as it was a TTX to start with!)
4. Give that to your client and they’ll be happy.
On the ProZ post you refer to. I didn’t read the post now, but based on your text I’m not really clear on the workflow. Were the Projects created in 2009 and then sent as a Package to the translator using 2011? If so the return package would be SDLXLIFFs and not TTX, so that the originator could update their project in 2009 and then create the TTX target files themselves. How did the files get converted to TTX and then get sent back to the originator of the request? I think, as soon as you start unpicking projects and sending files around, especially when you have so many then there is some potential for errors I can’t even begin to wonder about!
I never had any problem at all understanding *what a .ttx file* is. That was never at issue issue nor did I ask you to explain what a ttx file is. The issue was that ‘save target’ clearly implies saving a *monolingual* file containing the target only. As it indeed does if you save into original file format. It does not make any sense to me that ‘save target’ should be used to save a bilingual ttx file. That should be a ‘save as’ option. Also the fact that sdl calls the format ‘trados stag’ vs calling it ‘ttx’ made the feature much harder to find than it should have been.
I know that the .ttx and the .sdlxliffs are technically different animals, thus I had to check by trial and error whether I could save the .ttx from sdl, then reload it into sdl (autoconvert to sdlxliff) and still have the bilingual content and still be able to export the results to a monolingual .doc file. And that works, so great, only a bit of extra hassle for me to confirm that. But I still don’t know for sure if the .ttx file can be used in sdl 2009 or trados the same way. I assume yes, but the exact file format is still a black box so I can’t verify that, and that is why your remarks about the converter also concerned me. But there are many different scenarios for using the converter and I’m sure your remarks are quite well taken for some of those.
You have been kind enough to answer my questions, however you seem to have entirely missed the point of my complaint; I don’t think you really paid attention to what I said (tldr). Fair enough, it’s not really your responsibility, tho I did find it helpful to think someone might be willing to at least pay attention when I made a very reasonable statement about why sdl was hard to use.
But it’s your blog and I guess you want to have the last word.
Generally the process is this. You open a file for translation and when you save target you should get the translated version of that file. I think that’s simple. The exceptions, and they aren’t really exceptions they just come with an additional option, are other bilingual filetypes that Studio is able to recognise and also provide the ability to save you time by creating the monolingual file that was used in the first place. This is a feature that is unique to Studio for anything apart from the native bilingual format a respective CAT tool uses.
The use of Save and Save As is completely different, all relating to the SDLXLIFF. Studio does not place the segments into a database. You are working on the SDLXLIFF file. If Studio adopted your ideas then it would be handling two filetypes out of the 50+ it can support in a completely different way. That would be confusing.
The reality here is that you are taking a third party tool developed through the OpenExchange to solve a particular set of problems and comparing this to a process where the originating file in Studio is a TTX. This is completely different. The only similarity is that the XML file created for both TTX files is based on the TTX “standard” (if I can call it a standard as there really isn’t one). But one is monolingual to TTX to SDLXLIFF, and the other is anything to SDLXLIFF to TTX. The latter takes no account of the file that started the whole process at all. So trying to “clean up” (another old piece of terminology referring to updating a Translation Memory and removing bilingual tags so you are left with the fully formatted translation of the original monolingual file) the TTX created in the latter process would update a Translation Memory with different segmentation to the former, and would result in an unformatted Word document containing only text. Really, this is completely different.
I think what’s hard to use here relates to quite a complex issue around handling legacy bilingual files and what they are intended to be used for. I also think most translators just want to translate the files and that’s it… this is fair enough. But if you start getting involved in more complex workflows like this then you owe it to yourself to get a little education in localisation processes and it isn’t the responsibility of the CAT tool to provide this.
Actually, it seems to be that translators are forced to deal with legacy issues from the start because clients are using older versions of the software hence it’s very important to understand the backward compatibility issues. I was asked to return a .ttx file, this was not a whim on my part. I would rather not have to start off dealing with different bilingual file formats but it seems to me that’s where the world is right now. But for now, a couple simpler questions.
1. Do you think it was a good idea for sdl to call the function that saves as a .ttx file, ‘save to trados stag’? Was it reasonable for sdl to assume that since I know about .ttx format, I must know that ‘trados stag’ = .ttx?
Note: this in fact was not the case for me, and it’s very easy to imagine that there are many others who started using sdl 2011 without ever using trados not to know this. Sorry for harping on this a bit but I feel like you are dismissing my issues with sdl 2011 as illegitimate and this one caused me a lot of extra time, it would have been so much easier for me if they had just called it .ttx. Is there a good reason they called it trados stag and not .ttx?
2. What’s the difference between a file saved by sdl 2011 as trados stag, and the output of this sdlxliff to .ttx conversion tool?
I *think* you are saying that the file saved by sdl will have more information than the same sdlxliff file converted using the tool, but I’m not sure.
3. Is there any good use case (other than maybe pure convenience, less steps) for needing the conversion tool if I have sdl 2011 and can save into a trados stag file from sdl?
On your questions.
1. I don’t have an opinion on this one way or the other. But I can see how adding (*.TTX) to the end might be useful for those new to the industry. I also know that in the entire time I have been in this industry this is the first time I have had a conversation like this!
2. I recorded a video to explain the differences. I hope this helps! Not all TTX files are equal!
3. It’s nothing to do with convenience. You seem to be deliberately missing the point. The usecase is completely different and I hope you’ll see this when (if) you watch the video. The usecase for this additional tool is, in my opinion, only for being able to create a TTX file that you can share with another translator who is working with you so they complete the translation, or the review, in whatever TTX compatible tool they use. You then update your SDLXLIFF in Studio from the TTX they return to you.
But obviously you would only do this if you started life in Studio with a file that was not a TTX.
A general comment here. I understand why you probably consider me a bit arrogant, so I’d like to make clearer why I have strong views and feel confident about making judgments. Possibly thisbackground info might improve communication just a bit.
I spent 6 years doing QA on a java-based business integration platform, focused in large part on the Japanese version. The general model is that you have a java virtual machine which processes data sitting in the middle, on the outside you have lots of different legacy systems. You bring in data in all different kinds of formats, from virtually any legacy system you can think of, also from any of 6-7 mutually incompatible Japanese encodings. Within the java VM you can manipulate this data using any business rules you want. Then you can send the data back out to the original source, or you can send it to a file or to any of the other legacy sources, in whatever format and data encoding is required.
True, that product did not deal with the human language translation domain. But it did indeed deal with taking input source data from just about any legacy tool and format, manipulation in a flat data model, write to file and/or export to any, operation. Hence I think it’s very reasonable to expect my conceptual model to work without very much change in understanding even the more complicated aspects of sdl. It’s a very analogous – please correct me if I’m wrong.
I’ll try to be open to being corrected, but I want you to know why I feel confident about talking as an expert in ‘this type of software’. I’ll also say that one important role I played was to be a customer advocate. I reviewed designs from a usability standpoint, reviewed all the documentation, not infrequently had to push engineers and some of the technical writers, to see things from a customer viewpoint rather than from their ‘internals engineering’ perspective. This includes stopping them from making assumptions based on years of familiarity with the product, that don’t hold true at all for new users. New users should be able to easily find all the information they need to understand exactly what results to expect from any operation, and why. That’s a basic technical specification which is sine qua non of a technical product. It’s very important to listen to your users and understand how they see the product. If they find something hard to use, that usually means it was poorly designed.
That’s where I’m coming from, just so you understand a little better why I’m leaning on sdl :). We can continue argue about how reasonable I’m being, but that’s my excuse anyway.
I don’t think you’re arrogant. I think you probably have little else to do! I’d recommend you use the feedback in the product help as this goes to the SDL Technical Writers and QA teams. My guess is you’ll have something in common as opposed to leaning on me who is a little less concerned with the finer points you are bringing up, and bringing up, and bringing up and more concerned with just seeing things get done.
I may not respond to any more of these kind of posts because I don’t think they are adding any value to anyone, and are really misdirected by posting them at me. I think the actual problem of not understanding the workflows around TTX gets lost in a sea of words (even if they have value when directed to the right place).
Hopefully the video I recorded will be useful to others as well just in case anyone else is misunderstanding this workflow to the same extent.
Paul, you definitely provide much needed info in your blogs! This article and esp the one about what ‘clean’ means provide much needed info. So I agree that you are the last person I should be angry at. But, and it’s a big but, I don’t know where else to address my complaints and frustrations – I sent comments on the help pages but got zero response. And it’s not just that the help pages are not clear enough for newbies, it’s also that there should have been a tutorial explaining all the editor features and not having that becomes a huge tax on purchasers of SDL (especially until they find your blog and forum posts).
Your revision of the migration guide for 2014 is really great, tho I did not think to look there because I’m using 2011, (I think much of your new material there also applies to 2011 but I’m not really sure).
Anyway you are an incredible resource; you helped me turn my frustration into dialogue and then understanding, so I’m very grateful and also a lot more hopeful that I’ll be able to figure out how to make full use of the Studio 2011 product.
I’ll contact Technical Publications and see what’s happened to your comments. We have a fairly big userbase so it may be they have not got around to responding to you yet. In the meantime you could also take a look at this new application, once (if) you upgrade to Studio 2014 – Client Services CXM Plugin. This gives you a few more places you can go for help and share your thoughts in a place SDL will see it. There is a free community managed by SDL called the SDL QuickStart Community and as long as you have a Studio 2011/2014 license you can access this using your MySDL login (the same one you use to download your software and get license codes etc).
I will write an article on this soon as we will be marketing this app and the new community later this month, but feel free to drop me an email and I’ll give you the details now (as you have 2011 and won’t be able to use the app. since 2011 doesn’t support this level of integration)
Email is Paul Filkin.