Translating "smarter"

In response to my recent piece on the use of Fluency to translate Microsoft Publisher files, I received the following comments from the former's technical support:

It appears that you flat out ignored (or disabled) the warning message that pops up every time you try to open a Publisher file (attached).
There is no problem with Fluency with regards to Publisher. The issue lies in the fact that the Publisher interop is unstable. This (and the fact that professionals don’t use Publisher) are the reasons that CAT tools don’t support Publisher.
Are you hoping to ridicule us to encourage us to fix Publisher support? We’d just as soon remove support for it altogether, but we do have a few users who are grateful for it and understand that they might have to restart their computer a few times or kill the Publisher process that is frozen in the background. Another option that works, sometimes, is to try and save multiple times, which you discovered, but incorrectly attributed to resizing the view of the text (which doesn’t affect the output).
So we let you know before you start that Publisher is unstable and you’ve just spent a bunch of time documenting how it is unstable. To what end?
As for our XLIFF files, yeah they aren’t great, but extremely rarely is someone exporting something from Fluency to another CAT tool.
Regards,
Richard Tregaskis
Western Standard Support
Em: support@westernstandard.com
Ph: 801-224-7404

I'm not sure about the part that "professionals don't use Publisher". Certainly graphics professionals don't; when I earned my bread that way I usually used software like PageMaker, Quark Xpress or FrameMaker, nowadays Adobe InDesign seems to be the tool of choice. But I wouldn't think of some engineer in a technical department who uses Microsoft Publisher to write a manual as being unprofessional. Just foolish maybe, but no more so than the ones who use CorelDraw or even MS PowerPoint (!!!) in the same crazy way. People make the choices they do in the circumstances they work in, and professionals try to meet them at least halfway where possible to accomplish the necessary objectives. Fluency does that in the case of Microsoft Publisher, but one would do a service to the customer to suggest that another publishing platform might suit their needs better in the same way that responsible translation consultants often suggest that PDF is perhaps not the ideal format to provide for translation, and that the original format (if it isn't a Microsoft Publisher file or paper) might work better for everyone.

What concerns me about the response of Fluency's technical support, however, is the apparent lack of concern for the compatibility of their XLIFF files. If these cannot be exchanged readily with other platforms, one must ask what actual purpose they serve. Indeed, what would that be? And, perhaps, whether Fluency is really to be taken seriously as a professional platform for translation work.

Some years ago in a period where it looked a bit dark for my platform of choice, I thought that Fluency showed promise as a working platform, and I made a serious effort to investigate its suitability for my routine work as a translator of legal and scientific material. I was charmed by the generally functional approach to transcription, but the translation side of things was less encouraging, riddled with bugs at nearly every stage. After a few days I ran screaming back to more stable, well supported work platforms. The handling of SDLPPX (SDL Trados Studio package files) in particular was the sort of disaster one doesn't easily forget; even with products whose developers care about functionality and compatibility there are issues time and again as the SDL Trados platform evolves. I can only imagine what would happen with Fluency Now if I tried out one of those test files that a friend at SDL likes to play tricks on me with.

XLIFF is serious business. These days it is often the basis not only of interoperable processes with CAT tools but for all manner of bilingual exchange processes. And thus, until the technical support and/or development department of a tool takes this format seriously and makes a reasonable effort to ensure at least basic interoperability, that tool cannot be taken seriously for professional work.

That should be a question mark, not a period :-) 

Translating Microsoft Publisher files

Every few months or so I run across a question in social media or am confronted with a project like this:

Some time ago, Paul Filkin published an interesting discussion of an Open Exchange application that enables SDL Trados Studio users to deal with the Microsoft Publisher format with some limitations; in the article, he also discussed other approaches, including one I have known about for some time: the use of Western Standard's Fluency. 

I looked at Fluency some years ago, and while I found some interesting things there, such as its transcription module, on the whole the application never seemed ready for prime time with its sloppy programming of details. I spent some time trying to persuade its underfunded team to correct some of the problems I saw, but after a while it became clear that the company and its product were not able to cope with the demanding technical challenges routinely faced by language service providers today.

The discussion which followed the posted question suggested a number of approaches, but if the colleague's client expected to receive a translated PUB file instead of some other format, the only realistic option for this possibly one-off job would be to use Fluency in some way. I assumed (and suggested) that a workflow involving

  *.pub <-> Fluency <-> (exchange format) <-> memoQ

might do the trick (with the exchange format probably being XLIFF, but otherwise the bilingual RTF format that I remembered from my tests of Fluency long ago.)

And so it proved to be. But the Devil is in the details.

The first sign of trouble came from a colleague - a professor at a local university who is known for his technical curiosity and flexibility in translation courses - who told me that Fluency does indeed offer an XLIFF export but that memoQ experienced problems importing it. His description of the error message sounded a lot to me like the typical mistakes that CAT tool programmers who are XLIFF newbies make when implementing a spec that they are probably too lazy to read and test. (I found the same error myself and submitted it to memoQ Support for comment a few hours ago.) He said that he had then tried the RTF export, but it wasn't clear to me what the result was and he was under time pressure, so I didn't press the matter but resolved to have a look myself.

I used a modified English template file for an invitation as my PUB file to test. The file imported easily into Fluency:

I assume that "terminology" download is some silly, unhelpful public domain dictionary I would never use.

The Fluency user interface offered a sort of WYSIWYG representation for the text, which makes it appear not bad for work, though appearances are deceiving. In fact, this proved to be a source of some trouble later.

As mentioned, the XLIFF export could not be used in memoQ, and although I am capable enough of analyzing structure problems in a tagged file, I wasn't in the mood to clean up someone else's mess, so I exported a "Fluency Work File" as my next attempt. That is app jargon for a bilingual RTF file similar to that found in other applications.

The difference with Fluency RTFs is that they include the WYSIWYG text representation. Nice, really, and this makes the work in another environment a little easier. I copied the source text column and pasted it into a new file (DOCX), then imported that to memoQ for translation:

Afterward, the translation exported from memoQ was pasted into the target column of the Fluency Work File (bilingual RTF exchange file). I imported that bilingual file back into Fluency and then exported a translated PUB file using the File / Save As command. I got a strange error message saying that there had been some trouble with the export and that some manual adjustment might be needed in Microsoft publisher.

At first glance I thought, "Looks OK" and then... WTF???  Everything was OK except the title. Not only was the text cut off, it was not even the text I had translated in German. When I copied the text out of the field and pasted it into Notepad, this is what I saw:

Tag der Tag der kulturellen Vielfalt
kulturellen Vielfalt
Vielfalt
kulturellen Vielfalt
kulturellen Vielfalt
Vielfalt
kulturellen Vielfalt
kulturellen Vielfalt
Vielfalt

No joke. Fluency somehow went berserk exporting the text of the title field, and sliced, diced and multiplied the whole mess in a truly bizarre way.

In my nearly 5 decades of casual and occasionally professional programming I have seen almost every stupidity imaginable, so in this case I imagined that somehow the problem lay in sloppy programming associated with text that is longer than the space provided in the field. Interestingly, Fluency enabled me to change the size of the target text in the translation window, so I reduced it by about half and tried to export a new target PUB file.

That worked in fact. So Fluency can indeed be used as a sort of filter for Microsoft Publisher files to be translated in other tools such as memoQ, but the process is not without trouble on the Fluency side, at least when text overruns the field size available, as one might expect to happen with some frequency.

Western Standard offers a 15-day trial of Fluency Now, their desktop tool for freelance translators, and the application can be paid on a monthly subscription of only 15 US dollars. So perhaps for the occasional project or client that requires work with PUB files that is an option. Microsoft Publisher is not taken seriously as a layout and publishing tool by graphics professionals and CAT tool providers, but because it is part of the Microsoft Office suite, one will find it in use from time to time, and this imperfect solution may be the best option for helping such clients.