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 :-) 

memoQuickie: keyboard shortcuts for migrants (updated)

(PM - Pro - 2013R2 - 2013 - 6.2 - 6.0 - 5.0)

You can adapt memoQ keyboard shortcuts to your personal preferences or to be ergonomically compatible with other translation environments tools you use frequently for better productivity and reduced risk of errors.

Although keyboard shortcuts can be managed in the Resource Console, it is more useful to do so under Tools > Options… > Keyboard shortcuts, because that is the only place where a given set of keyboard shortcuts can be selected for use. Marking the checkbox for a list in the dialog shown above will make it the active one.

Look carefully at the keyboard shortcuts available in memoQ. Not all of these commands are found in menus (for example, the shortcut for quick search with selected text in a translation grid, Ctrl+Shift+F by default). To examine a set of keyboard shortcuts, select it and click Edit to show the list.

To change a keyboard shortcut, select the value in the Shortcut key column of the editing dialog and press the new key combination.

The truth about memoQ 6.x and XLIFF

Lately there has been a lot of disinformation and misinformation being spread by people presumed to be memoQ or other CAT tool 'experts'. What is an 'expert' anyway? A good working definition, I think, is that an expert is someone who is clueless at a higher level. Read whatever you like into that; many days the worst interpretations apply very well to me.

It is often assumed and sometimes explicitly stated that, with the introduction of memoQ version 6 and the new MQXLIFF and MQXLZ (a ZIP file with XLIFF and other resources) formats, memoQ has taken a step backward in compatibility and can no longer produce ordinary XLIFF (or *.xlf) files. This is simply not true!

Kilgray doesn't exactly help the situation by talking about renaming MQXLIFF extensions to XLF; in fact, I have roasted the chief developer of Kilgray slowly over hot coals for this and other silliness and told him how I think this all ought to be handled. (And knowing Gábor, when he does fix it, he'll exceed my best imagination in the quality of his concept.)

But as is often the case, those geeks at Kilgray actually solved the 'problem'; they just forgot their own solution or forgot how to explain it coherently.

First of all, it's important to get the settings right. In memoQ, XLIFF files are saved from the Documents or Views tab of Project home > Translations, by choosing Export bilingual, and the correct settings for the bilingual (XLIFF) file to be shared with other environments or older memoQ versions are:

 

I have boxed the relevant area red for better clarity.

When saving the file, simply change the file extension in the name of the file as you save it as shown here:

When the exported bilingual file is saved to a folder in the file system, a quick check confirms that renaming the file extension in the Save dialog works. (I do this all the time in other software like Notepad).

Now the file can be recognized without further ado and imported into most other environments for translation. The only real "troublemaker" here is, of course Trados. As I reported in September 2011, there is a bug in SDL Trados Studio which screws up the import of XLIFF files in many cases if the sublanguages are not specified or the default major languages do not match. SDL has many priorities, but often it seems that compatibility and standards compliance are not among them; to this day AFAIK the bug remains unresolved!

For users of other tools, this means that to exchange data with Trados users for any purpose, you should get in the habit of specifying sublanguages. This means DE-DE, DE-CH or DE-AT instead of DE for German, EN-US, EN-UK, and so on instead of EN for English. Ain't it great? Brought to you by SDL development. Maybe they'll do a better job once the move to Cluj, Romania is complete ;-)

Update 2013-07-24: Here is a short video illustrating the process of exporting XLF files from memoQ and opening them in SDL Trados Studio: