Another look at Wordfast Anywhere

The Wordfast suite of applications has a long history, and through much of it I've had my eye on the tools but up to now never really found them up to the demands of my work. Wordfast Classic (back when it was the only Wordfast app) was brought to my attention by an enthusiastic manager of a German bank's translation team more than 15 years ago; he found that the "blacklist" feature for terminology (since adopted by others - for example in memoQ's "forbidden" terms) was extremely helpful to his translators in avoiding terms which might provoke branding controversies or which were simply inappropriate in a particular specialist context.

When Wordfast Pro came along, I was disappointed in the interoperability of its early versions and it being late to the party for supporting XLIFF formats (as were some other popular tools). That issue is solved in the meantime, so I suspect I might not be quite so unhappy were I to revisit the application.

But really, Wordfast doesn't come onto my radar very often, and when it does, it's not so much the application suite itself as it is the Wordfast creator - Yves Champollion, who follows in a way the family tradition of the famous French Egyptologist, Jean-François Champollion, translator of the Rosetta Stone, and who has earned his own fair share of praise for his many years of support for individual translators and their professional organizations. It would not surprise me if much of the loyalty I find among users of Wordfast is inspired by the personal qualities of Yves as much as by any technical features of his tools.

The least among these tools was, in my consideration, the web-based Wordfast Anywhere (WFA). I looked at it briefly in the early days and was unimpressed: too limited, I thought. And the idea of translating in a browser seemed dubious to me, and it remains so in many scenarios that are relevant to my work. WFA was a bit ahead of its time, before the scamming Gold Rush that targeted corporate clients for web-based solutions designed to wrest data and control away from translators. WFA wasn't welcome in that party: its focus on empowering individual translators is anathema to most of the web CAT solutions ones sees today.

My interest in Wordfast generally was revived recently when I saw that memoQ has integration plug-ins for Wordfast term bases and translation memories on servers. This inspired the thought that perhaps Wordfast Anywhere might function as a collaboration server here, sort of like some had hoped for the Language Terminal resources, but one that actually works perhaps. Alas no, or not yet at least; the memoQ plug-in cannot "see" the WFA server and an individual account. Oh, but if it could....

Collaboration and interoperability between translation environments have been topics of great interest for me since I began to use specialist tools for organizing translation resources some 19 years ago. And on those occasions when I want to share resources with someone who does not have a professional suite of desktop translation resources, I'm always a little uncomfortable with my default recommendations, because they are just a little too nerdy to work well with everyone. So I wondered... how well might WFA work with resources I prepare in SDL Trados Studio or memoQ and pass on to a colleague unequipped with those tools or other desktop solutions. I thought I remembered limits that would restrict such an effort, but either my memory is wrong or these limits changed.

WFA can accept files to translate which are up to 20 MB in size. I receive files that are sometimes larger than this, but not routinely, so this is not much of a restriction. But then I thought the limit on translation memory size would be the stumbling block, and indeed, when I tried to upload a 390 MB TM with about 330,000 translation units, I got an error message telling me that 300 MB (or rather 300000000 with no indication of units!) was the limit. Looking in the online documentation I found that 100,000 TUs is the limit for an individual translation memory in WFA. But you can attach multiple TMs and term bases (which can be much larger as I saw from the 800,000+ entry IATE termbase supplied by the environment). And most TMs that I see for mid-size companies are well under that size limit.

So I spent some time kicking the virtual tires again. Uploaded some damned big EU directives in various formats, including bilingual alignments in an XLIFF. No problem. Loaded a big memoQ XLIFF file: the *.mqxliff extension wasn't recognized, but I fixed that the usual way by changing it to *.xlf and it worked well, roundtripping perfectly back to memoQ and confirming that interoperability would work well enough for collaboration.

Indeed, the range of original file formats handled by this free online translation environment is impressive.

As I browsed through the options and customizing features of the WFA environment, my respect for its capabilities increased further. The thought occurred to me at one point that this might even be suited as an environment for a small company with limited translation needs to manage its language resources and make them available for in-house or external translators. With the several exchange formats available, translators and reviewers could easily perform their work with other translation environment tools or even word processors, and the results could be merged with the master records in the WFA account. This is probably the least expensive, secure way for a company to take its first steps toward central management of its translations and terminology resources. No big server investments needed, and later all resources can be migrated easily to more sophisticated environments, such as a memoQ Server, if necessary.

Some years ago, I opposed the use of Wordfast Anywhere in a local university program, arguing instead that more established professional tools like SDL Trados Studio and/or memoQ should be used instead, especially as the cost of doing so is negligible in teaching curricula. I take that back now. And my impression is that WFA is better suited to a teaching program than other, perhaps slicker web-based tools, because of the underlying philosophy of its design, which leaves translators and their partners in control of the data, not some third-party provider inclined to carry out dubious data mining and use the results to sell more dodgy commercial solutions.

Wordfast users also know that their desktop software can access translation memories and term bases on a WFA account as remote resources. My last look at Wordfast Pro showed me that the tool had come a long, long way since I last dealt with it to clean up some messes a French translator inflicted on an agency client of mine. It's been on my list to look at further for some time; I know it will likely not meet my criteria for the broad range of translation, quality assurance and consulting tasks I do, but it does do a good job of covering the real, practical needs of many colleagues, and it is important to me to understand other translation environments to facilitate collaboration with people who use them.

And for these cases of working together with a mix of environments, it seems to me that Wordfast Anywhere can be a productive bridge to bring partners together. To create a free account and start testing Wordfast Anywhere, click here.

Translating Wordfast GLP packages... elsewhere.

One reason to keep  translation environment tool licenses up to date is that new formats continue to appear. New formats for translatable files as well as new file formats for the tools that help to process files for translation. Very often I have heard some "professional" say "I'm a translator, not a [fill in the blank]. If the client wants this translated, I'll have to get it in a Microsoft Word file." Or something like that.

Let's get real for a moment.

• That attitude is simply lazy and disrespectful toward translation consumers who would like to make use of one's services and
• a lot of money is being left on the table here in many cases. I built a huge clientele at the start of the last decade, because my use of translation environment tools like Trados, Déja Vu, STAR Transit and Wordfast enabled me as an individual to tackle translation challenges that many agencies at the time had no concept of how to cope with.

As translation agencies have acquired more technical tools, most of them still remain unfortunately unaware of how to use them properly or plan more than the simplest workflows well, but that's a subject for another day. Also...

• ... by using tools and techniques that are compatible with what your clients require for a final format, you can save your client a lot of time and money for further layout work - and probably avoid the introduction of errors in your translation work in its final format as well.
• And in my experience, showing technical and process competence to benefit clients usually leads to greater trust and better work together.

So what has all this got to do with Wordfast?

Well... I didn't like the Wordfast brand for a very long time. Its various incarnations were perhaps the weakest of the popular tools in a technical sense, and inevitably when agency friends called me, desperate to fix some massive translator screw-up (usually by somebody in France), Wordfast "Pro" was often involved in the disaster.

I looked at the "newer" Wordfast versions a number of times over the years, and honestly they always seemed like lobotomized wannabe tools. This was about the time that many other toolmakers were trying to decide if they should support XLIFF.

Well, a lot has changed since then. I became aware of the changes the other day when somebody posted a question in a social media forum for memoQ asking how to handle Wordfast Pro 5 GLP packages. I had never heard of these, so of course I was curious and decided to take a look. This finally led me to download a 30-day trial of the latest Wordfast Pro software to evaluate its potential for interoperable work with other translation environments. I see a lot of changes since my last look, and so far I think they are all positive, and along the way I had good cause to look at Wordfast Anywhere, the free web-based CAT tool that I talked some university colleagues into not wasting their time with a while ago. Well, my recommendation in that regard might change, but that and commentary on the latest incarnation of WF Pro will have to wait for another day.

About those GLP packages....

Yes, those. This was the question:

Someone pointed out that GLP files - like every other translation "package" one finds from all the tool providers - are merely ZIP files with particular structure inside and the extension re-named. 

Gotta love Facebook. You'll always get an answer in some group, usually a wrong one. That's why I keep a blog. Good information gets buried in social media noise too often, and good luck finding it in any kind of search. In this case... we don' have no steenkeen TXML files as I learned... that's the old Wordfast Pro....

A colleague in Germany kindly provided me with a little GLP package to examine, which I promptly unzipped. I noticed that at least one tool (7-Zip) sees through the renamed extension nonsense and saved me the usual trouble of renaming it before unpacking.

So far, so good... inside the folder for the unpacked GLP file I found the following:

The test package was an English to Portuguese project. But source? Hello? Let's have a look there!

Very interesting. The original source files (English) came along for the ride. This is good, because I often like to translate source files in memoQ - taking advantage of the preview there for many file types - and then use the translation memory to translate the file that is created by other other tool (usually SDL Trados SDLXLIFF files in my work). Now let's have a look inside the pt target folder. There's actually another folder named txlf inside that one. And there I found:

No TXML files! TXLF is a new instance of the rather ubiquitous XLIFF files one finds in the translation world, some of which have some rather bothersome "extensions" that may require special handling in the translation process. In the simple test I performed, none of that was apparent; an ordinary XLIFF filter seemed to work well. Future tests will show me if there are any quirks I hope, but so far, so good.

So one strategy, with pretty much any CAT tool, would be to unpack the GLP file, get at those TXLF files and then bring them into another working environment using an XLIFF filter. Maybe also use my approach with the source files too, which will ensure that you can deliver a good target file even if quirky tags in the XLIFF lead you to produce less than an optimal result there. 

The current version of memoQ (8.4) does not recognize the TXLF extension, so as in all such cases, the All files option must be used and the correct filter applied in a later dialog. Unlike with some other tools, memoQ cannot be "trained" by the user to recognize new extensions as far as I know.

But what about importing the GLP files directly to memoQ? Wouldn't that be nice? And I thought it might be possible using the ZIP file filter recently introduced (and the same All files trick to get the GLP file and apply the ZIP filter later). Well...

It looked promising.

So much so that I even optimistically named and saved a custom configuration for the ZIP filter. All I need to do now is cascade an XLIFF filter!

Ack. Sooooo close. I've been here before. There are more things in heaven and down-to-earth cascading formats, Kilgray, than are dreamt of in your philosophy! Please, please expand the list of possible cascaded formats sensibly to make better use of this lovely new ZIP filter!

So for now, that's a no-go, but soon? Who knows? If you bother support@kilgray.com and tell the memoQ team how helpful it would be, maybe this and similar problems can be solved with relative ease.

In any case, for now it seems that the unpack-and-do-the-XLIFF approach will work for most anyone with a modern CAT tool. And that's good news, because in today's fast-changing technology environment for translation, interoperability of CAT tools is increasingly important. It is a foolish waste of time to translate in a large number of CAT tools and probably a bad idea to do so in two or three according to my old research. I've usually found that such JOATs are, professionally, often stupid goats who lack the depth in a single major environment or two, which could allow them to get the most out of their tools and serve their clients in the best way with their linguistic skills and subject matter knowledge.

So is the latest Wordfast a tool worth checking out? I don't know yet. But it may be used by colleagues and clients with whom I like to work, and understanding how to share projects and project resources in painless ways will benefit all of us, no matter what our tool preferences may be. Wordfast seems to be developing very much in that spirit, so I will revisit it for more collaboration scenarios in the future.

ODT files in translation environment tools

After an interesting afternoon with a friend who was a bit frustrated with the behavior of her translation assistance technology with an ODT (Open Office text) source file, I decided to have a look at how a variety of common tools handle this format. I created a small test file which contained some of the troublesome elements and saved it as *.odt for testing. The test file looked like this:

The ordered list was created using the numbering feature.

When the file was imported to OmegaT, the segmentation looked as follows:

Fairly clean, though the segmentation is a bit off due to the encoding of the space after the end of the sentence in the second block of text. Nine segments where there should have been ten.

With memoQ, the result was:

Altogether there were a dozen segments after import. The part with the hyperlink was segmented incorrectly in three parts instead of one. However, memoQ did handle the space tag after "tool." correctly and start a new segment at "Here". Once can, of course, use the segment joining function to correct the segmentation until Kilgray gets around to fixing the segmentation on the hyperlink tag:

Update 9 January 2012: The developers at Kilgray have informed me now that this quirk in the ODT filter has been corrected and will be included in the next build released.

When I tried to test my SDL Trados Studio 2009 license, at first it refused to joint the party:

Never a dull moment with SDL as we all know. Of course SDL Trados 2007 was in fact installed, but when I upgraded to Studio 2009, of course it trashed my 2007 installation, and I had been too irritated to do anything about it for over half a year since I don't use Trados for anything more than file preparation and compatibility testing anymore, and I was still able to do that for my projects with the damaged installation. However, when I discovered that the ODT file caused TagEditor to run and hide without even saying goodbye, I sighed deeply and wasted half an hour reinstalling SDL Trados 2007. At least I didn't have to go through that insane check-in/check-out license procedure online. I trusted in God and my Windows Registry entries, and the location of my license file was remembered, so all was well.

The second attempt at SDL Trados Studio 2009 was much better:

Same segmentation problem as OmegaT, and examining the tags reveals where the issue might be addressed in a tweak of the filter.

I haven't got the latest upgrade, but someone was kind enough to run my test file through SDL Trados Studio 2011, which appears to offer the best results for filtering ODT (the settings were slightly different, with the URL included, but that is also possible with some other tools):

SDL Trados TagEditor also worked after re-installation. The results were:

Oh dear. Well, it works, but if I still used TagEditor, I would run, not walk, to the much cleaner interface of OmegaT for this sort of thing if I didn't have the good sense to upgrade to Studio or something else commercial. Note the same segmentation issue and the need for filter modification.

Victor Dewsbery was kind enough to import my test file to the original Atril DVX and the newer DVX2 and send me the results:

DVX import of the test file

DVX2 import of the test file.

I also tried to test SDLX, Wordfast Pro and Wordfast Anywhere. The first two tools don't support ODT. Wordfast Anywhere claims too, but went nowhere, with the following status message displayed in my browser for about half an hour before I gave up and went to lunch:

Of course I canceled. I had a blog post to write and a New Year to get on with. Anyone who wants to try the test file in another tool (to compare apples with apples) can get it here.