The Techno-Marketing Hybrid

Back in February I promised to write about the relationship between technical information and marketing tactics (Will Controlled English Take Over Technical Communication?). I just translated a technical text that was clearly intended as a marketing tool. Documents like this one often include "purely technical" information, such as tables with specifications and parts lists, but the bulk of the text is intended to convince potential buyers of the superiority of the particular product.

There is an inherent tension between technical and marketing speak: Technical information is highly specific and full of terms with very precise meanings in the field in question. Marketing text, on the other hand, tends to be much more vaguely worded, including phrases aimed at emotions and devoid of actual meaning. Combining these two very dissimilar writing styles is an art, but can leave a technically minded translator scratching her head.

I must confess, when I read that someone's ball bearings are superior, I immediately think: "Says who? Why or how are they better than anyone else's?" Sometimes technical-marketing hybrids will actually answer that question, but more often than not, they will simply assert that this is so. The accompanying table will then add some numbers, but without offering corresponding numbers for other, similar products.

Presumably the intended audience for these documents does have an idea what these numbers mean and whether higher or lower values are better for a particular feature. But I doubt procurement managers memorize the standard specifications for all -- or even most -- items they order. So how do they decide which ball bearing to order?

Many of these hybrid texts land in a technical translator's inbox, rather than being translated by someone specializing in marketing. Even though I much prefer straightforward technical information, I have had to learn marketing speak in order to handle these types of texts. Living in New York City surrounded by advertising does help me come up with appropriately "salesy" terms. Superior ball bearings? - ah, yeah, that's what that sign in the hardware superstore said. So I guess it's a common term...

ATA Conference Boston - Review of Sessions I

German-English translator Annette Cyrkel took this photo at one of the networking breakfasts at the recent ATA conference in Boston and graciously let me use it. Here are my summaries of three sessions on technical translations/terminology. I'll review two more sessions on the business/marketing end of our profession next week.

• "A Dilemma for Language Service Providers and Translators: Subject Matter Expertise and Internet Style"
• "Technical Writing for Into-English Translators"
• "Search-fu! Finding Terminology on the Internet"

"A Dilemma for Language Service Providers and Translators: Subject Matter Expertise and Internet Style" by Manisha Mittal

Ms. Mittal works for Language Scientific, a translation agency specializing in technical and scientific documents. She explained how her agency analyzes incoming projects and matches translators, subject matter experts and editors with a specific project. Unlike more generalized language services providers, Language Scientific requests fairly detailed information from its end clients. This includes target audience, specific speciality within a subject, type of text, in-house style guides and glossaries. It then assembles a team of translators, editors and proofreaders, at least some of whom are also subject-matter experts in the given sub-speciality. The agency is looking for additional freelancers.

"Technical Writing for Into-English Translators" by Karen M. Tkaczyk

Ms. Tkaczyk defined technical writing as text that conveys informaton accurately, explains technical ideas and is focused on the user. For a technical writer a romantic poem simply becomes "John loves Jane." She then provided a number of specific tips for editing your translation into better technical writing, such as:

• write concisely; if necessary, divide long sentences into multiple shorter ones
• reorder thoughts to make them logically coherent or to present events in the correct order
• turn nouns into strong, active verbs

Translators should pick a specific style guide to follow whenever a client doesn't specify a particular style guide, Ms. Tkaczyk suggested. The presentation concluded with a list of common stylistic errors, such as spacing between units of measure. An extensive list of resources was provided in a handout.

"Search-fu! Finding Terminology on the Internet" by Alex Lane

Mr. Lane focused on the ways in which Google searches can be customized to return the specific results a translator might need. One of the most useful, I think, is the fact that a search query can contain words in more than one language. Google will interpret the languages concerned and return bilingual texts that fit the query. Other ways to find terms include exploiting a site's URL structure to find the same document in a different language (e.g., if a search returns www.example.com/English/document1.html, replace "English" with "German" to see document1 in German) and restricting searches to specific sites or sites with a specific country code. Mr. Lane recommended keeping track of the searches performed, in case terminology choices are questioned later.

Why Don’t People Read the Documentation?

It looks like this is turning into a train blog. This time I'm sitting in the train back from Salzburg, Austria, where I visited an uncle who makes flight simulators and also supports them. He told me how customers don't read the documentation he wrote, but instead call him whenever they have trouble operating his equipment. That seems to be a universal problem for technical writers: customers don't bother to consult the help files or printed documentation, then complain if the equipment doesn't work the way they think it should work. They think, for example, that a specific action should be triggered by a particular button. When that button doesn't perform the action they expect, they call the customer service desk rather than consulting the documentation about the correct button to press.

On the other hand, how often have you and I attempted to decipher badly written, badly organized and/or badly translated documentation for some device we bought? Small wonder that customers give up on even trying to consult documentation after they have encountered a few such texts that were written in programmer speak, contained factual errors or were translated into garbled English. If customers are to get into the habit of consulting help files or booklets, they must consistently encounter files or booklets that actually help them solve problems with the devices they handle.

This, in turn, means that the documentation -- in whatever form -- must not only be accurate and well written, but also well-organized, with a device's particular audience in mind. A cell phone intended for senior citizens, for example, needs to be accompanied by an extensive printed booklet illustrating each step with large screen shots. A software developer kit that lets programmers write code for a certain computer platform, on the other hand, requires only very specific online information and can include acronyms and IT terminology.

While technical writers need to keep their audience in mind when writing the source text, we translators all too often forget -- or never know -- who might be reading our document. Just as the original writer's word choices depend on the target audience, so do ours. Sometimes we can glean from the source document who the likely readers might be, as in the examples cited above. But if that is not obvious and the client didn't tell us, we should ask. No need for extensive audience analysis, but the answer to "Will this document be provided to the consumer or to the technician servicing the device?" or a similar question should provide enough information so that we can gear our choice of vocabulary and sentence structure towards the target audience.

If we consistently ask this question, agencies and end clients will get into the habit of providing that information with the project. This will (hopefully) result in documentation that is useful to the end consumer, leading to them actually reading the documentation.

International Technical Translation Conference

Last week was rather busy, what with all the work accumlating while I was in Portugal. Now that I'm (sort of) caught up, here is my take on the Tradulinguas Technical Translation Conference in Lisbon:

On Friday, I attended the following presentations:

• Mathilde Fontanet's session on translating English technical texts


• Suzanne Goujan's lecture on renewable energies terminology


• DeAnn Cougler's presentation on terminology management


• Jerzy Czopik's "Tagology for Dummies"


• David Hardisty's talk on technical translations into English as "language B"

Mathilde Fontanet works for the translation department of CERN, the Swiss particle collider. I hadn't even known that CERN had such a department, but given the international collaboration this project requires, it makes sense to have a team of in-house translators. Ms. Fontanet spoke about some of the difficulties she and her colleagues encounter in their work. For one, English technical texts are often written by experts whose dominant language is not English. Having just finished a large software translation project myself, I can attest that this problem isn't limited to English, but can happen with German originals, as well. In addition, Ms. Fontanet said, U.S. technical texts frequently don't conform to European Union requirements in terms of the information that must be included (e.g., safety and environmental statements, ...). Translators aren't only transferring meaning from one language to another, they are also the original text's editors/proofreaders. Such functions distinguish human translators from machines, but that only becomes apparent if the human points potential problems in the source out to the client (and/or fixes them, if they're obvious errors).

Suzanne Goujan offered a number of (English) definitions for various terms used in the renewable energies sector. It had likely taken quite some time and effort to amass this information, but the lecture added little beyond what could be read in a book or handout. I had hoped for more discussion and examples in an in-person session.

DeAnn Cougler offered some helpful suggestions on managing terminology as a freelancer, as well in-house. She recommended scheduling a daily time slot for terminology work so that one's own database remained well maintained, making work easier and faster in the future. I should really do that, since I tend to stop working on terms once I complete a project. Over time, this leads to a jumble of terminology files that could use an organizational overhaul. Ms. Cougler also suggested tracking time spent on terminology research and offering such work as a separate service to clients, invoiced either by the hour or by the term. While that sounds like a good idea, I am not sure how many clients would be willing to pay for it. As far as they are concerned, such (sometimes time-consuming) work is part of what they pay for -- even if that pay is relatively low.

I had heard Jerzy Czopik speak at the ProZ conference in Vienna. This time, he talked about the tags inserted by many CAT tools into the text. While the talk was informative, much was familiar to me from my work coding HTML and XML/XSL. However, he recommended a tool, CodeZapper, that removes unnecessary formatting in MS Word. I'll have to try that one out (sounds like there is another follow-up post to be written...).

David Hardisty teaches technical translation into English at the Universidade Nova de Lisboa, where most students' dominant language is Portuguese. Many of his students will end up translating into their non-dominant language. Mr. Hardisty highly recommended Brian Mossop's book "Revising and Editing for Translators", which I'll have to check out. It does sound like a useful resource. He also thought that it would be helpful if technical translators took a class in technical writing. Having been a technical writer myself before becoming a translator, I very much agree.

The conference was held at the Universidade Nova de Lisboa. During lunch, another translator and I got lost and ended up in the student cafeteria. Fortunately, my companion spoke Portuguese, and we had quite an interesting lunch amid a crowd at least 20 years younger than either of us. Made me feel a little like I was back during my own student days ...

The Changing Role of the Translator

I just read an interesting op-ed by David Bellos in last weekend's New York Times. In "I, Translator", the director of the Princeton translation program offers a brief overview of machine translation, from its infancy in the U.S. at the start of the Cold War to its current Google Translate iteration and concludes that machine translation cannot replace human literary translation.

A point well taken, but literary translators constitute a fraction of the translation community. Most of us don't work on War and Peace but on such prosaic texts as legal contracts, medical documents or technical manuals. Quite a bit of these documents consist of "boilerplate" or otherwise at least semi-standard text -- that's why translation memory tools have become so useful to human translators. Because of this standardization and repetition, such technical text does lend itself to machine translation, just as the original text is a prime candidate for standard content management systems. This move towards further automation may put both translators and technical writers out of business -- unless we adapt.

As Google Translate and similar systems parse ever-increasing quantities of multi-lingual web content -- including my own bilingual website -- their translation engines approximate human translation ever more closely, at least in relatively common language combinations, such as German-English. But while a business contract doesn't need to be good prose, it does need to be extremely accurate -- approximation just isn't good enough. That's also true for medical and technical texts. So while Google Translate can provide a basic idea of what the parties to a contract agreed upon or how to operate a particular piece of machinery, humans still need to ensure that nothing has been mistranslated and that the end result flows smoothly and is easy to understand.

That's where we human translators come in: as editors to verify and refine the somewhat crude machine translation. To some extent we are already performing this role when we edit the "fuzzy matches" provided by our translation memory tools. Post-editing machine-translated text would be similar, just with a much larger translation memory. The question now becomes: how do we come up with a compensation model where we can still make a living, even though this editing will garner a much lower per-word rate than traditional translation?