Interoperability intelligence

In eight days I'll be giving a presentation at the memoQfest 2010 on interoperability - using memoQ as a collaboration tool for translators and reviewers who use other tools or leveraging features in other tools to achieve things that would be possible with memoQ alone or using memoQ to do the same with other translation environment tools.

I've already written a few posts of this nature, particularly the one discussing Déjà Vu as a collaboration tool and another focusing on the classic Trados software. Sometime before or after the talk in Budapest I'll do the same for memoQ. And it would be possible to do this for SDLX, OmegaT, WordFast and a host of other tools. However, given the wide range of combinations possible and the variations in individual needs, I think it's more important to consider the general concept of tool interoperability and strategies for applying that concept in the most useful way.

Ill-considered interoperability - exchange of TM or translation file data, terminology, etc. - can be troublesome. Although I like to consider myself an expert in using various tools to produce results that satisfy the requirements for other tools, sometimes in the rush and pressure of a heavy workload I make a bad choice and produce data that does not give my client exactly what works best for re-use and reference or functions best in the client's review workflow. So I need to slow down in many cases and think about what is really needed. Intelligent interoperability is called for.

On one hand you must have a clear picture of what is needed. The deliverables for the client should be agreed and specified exactly. How many times have I read frustrated forum posts in ProZ and elsewhere from translators who have done a job, delivered the target language text and then been asked for the "uncleaned files"? "What is that?" they ask. On busy days it's hard to remember to ask all the right questions to be sure that the specifications are clear, so creating a checklist might be useful. And possibly also a written description of your standard workflows and default deliverables. Without some clear starting point you may not understand where a project is headed, and you can end up lost and confused very quickly.

Deliverables specifications are not enough. If, like me, your business strategy involves working with a wide range of formats and tools, it's important to understand the interfaces available, how to use them, and the strengths and weaknesses of each interface. Create "maps" for yourself that show how to get from the source format to your working environment and back with all the information needed by the client.

Let's take Microsoft Word files as an example. Simple, right? In your dreams. Or nightmares rather. Clients use MS Word in totally insane ways that drive translators and translation software crazy. Simple files can be handled by most any tool. But there can be complications:

• The old Trados Workbench macro tools in MS Word freak out with cross references. This used to give me major headaches.
• Some versions of TagEditor can't cope with section breaks if they aren't followed by a carriage return.
• Déjà Vu has a bad tendency to choke on MS Word or RTF files with a lot of graphics. Or even a few graphics of certain types.
• memoQ has its issues with graphics-laden Word files too

I could add a dozen more points to this list of possible complications, and I'm sure that readers of this blog could point out at least another hundred possibilities I've missed. No matter what translation environment tool you prefer, it's important to understand how robust it is when faced with various complexities in the formats you translate and how potential weaknesses can be compensated. For the third point above (DVX failing to import a DOC file with lots of graphics - or taking hours to do it), part of my "map" involves creating a TTX in Tag Editor, which imports quickly into Déjà Vu, but there one must take the precaution of making sure that the TTX created can in fact form a target file when you are done. This isn't a point to be taken for granted with the classic Trados software.

Part of the process of creating these maps is to document the interfaces clearly. What formats can be imported and exported? memoQ, DVX and some other tools can import dozens of file formats and make the content available for translation in many different ways: as XLIFF, text in RTF tables, bilingual Trados-segmented DOC files and more. Any TEnT can handle at least one of these possibilities. But sometimes there are process vulnerabilities in the data exchange, and these must be understood and documented to avoid trouble with clients!

Unless you are dealing with naked text files, there really is no such thing as a "simple" format per se for translation. And sticking your head in the sand won't make the problem go away: clients will continue to embed all kinds of crap in those RTF and Word files. Ready or not, those files will come to you. What happens at that point is up to you.

Many translators and translation agencies are simply not up to the challenges involved here in the data engineering. This is not a criticism, just a fact. There is a real need I think for affordable, accessible consulting resources to help meet these challenges, but 20+ years of activity as a consultant in the corporate world have made me a bit cynical about the overall prospects for useful help in many cases. When I think of all the computer "consultants" waiting to screw up the configuration on hard drives around the world I cringe.

Tool vendors could help the situation somewhat by focusing on solutions, including integrated solutions that may involve components that come from other sources. This has long since happened in the IT world in general, with competitors cooperating to get a contract where none could satisfy the requirements alone. Will we see the day when Kilgray and SDL work together to create an integrated solution for a major client? I hope to see that or similar configurations focused on the real needs of the clients. Think solutions, not tools and common-sense, practical, useful interoperability is more likely.