Desktop Publishing and Quality Assurance in Translation

I head up the desktop publishing and quality assurance division of U.S. Translation Company. My department, in the best-case scenario, flies under the radar. If we attract attention, that’s a bad thing, because it usually means we’ve done something wrong. If we do our job right, the client won’t even notice our work. They’ll only notice that the translated product meets their expectations. Naturally, that is what we try for with every project. It doesn’t mean it always works out that way.

Complications in Quality Assurance and Desktop Publishing

When complications do arise during the quality assurance or desktop publishing processes, they usually occur because of what we don’t know. Or, even more accurately, because of what we don’t know we don’t know. We love our clients, but, like the rest of us, they sometimes make assumptions. Assumptions, for example, about what a finished product will entail. Most of the time those assumptions line up with our standard processes and procedures. Occasionally, they don’t. In the latter case, they usually involve quirky layouts or other specifics that we would never guess.

Mitigating QA / DTP Misunderstandings

Sometimes, we see the same client expectation pop up multiple times. For example, some clients want specific aspects left in English, such as measurements. While we would never know that they expect measurements to remain in English, once we see the same issue crop up a couple times, we make sure to incorporate a question about that issue into our client onboarding process. “Are there any parts of this text that you do not want translated? Measurements, for example?” We also create client style guide to pass on to our translators. The style guides act as profiles of client preferences and patterns, and address individual quirks and preferences that we’ve gathered over the process of working with a client, often learning them the hard way. And, the profiles help tremendously, allowing translators and my team to proactively customize and thus avoid rework.

Quality Assurance and Desktop Publishing Wildcards

Just when we think we’ve seen every client expectation — and incorporated them into our screening and onboarding process — we occasionally get blindsided by a new requirement that we would never have imagined. A client, for example, might want specific terms left in English, and assume that such a requirement would be obvious. Or, even more complex, they may want those terms in English with their translated variant following in parentheses. They may have preferential wording for the final (translated) product: our translator made one valid choice, but the client had a preconception that a different phraseology was more in line with their vision.

They may want a specific font but neglect to tell us. Fonts vary considerably in the amount of space they require; e.g., a standard Word document with default margins will, in 11 point Arial font, allow 84 characters per line. Given identical parameters, 104 characters of Garamond will fit per line. Switching from Arial to Garamond, then, will shrink a translation by 23%. So, a change of font may cascade into a number of additional formatting considerations.

Alternatively, the customer may want their company letterhead incorporated into the translation — even though it was not in the original; they may want a table or graph omitted, shrunken, expanded or untranslated. In short, the individuality of client needs, apparently, knows no bounds.

Delivering an Individualized Translated Product

True to the U.S. Translation Company ethos of white glove service and our goal of total customer satisfaction, my team and I see each quality assurance or desktop publishing project as a unique opportunity to deliver flawless personalized results. We congratulate ourselves when we achieve that goal with no hitches, and we learn from hiccups and incorporate those experiences into our repertoire of things to be aware of.

Other Common Quirks and Customizations to a Translation

When performing quality assurance and desktop publishing on a translated document, we ask the client about a variety of known points of confusion. Example: does the client expect to receive a final print-ready document? They may assume that we would deliver such as a matter of course. However, getting a document print-ready involves desktop publishing, which is an additional process above and beyond standard quality assurance.

It would be easy for a client to assume that we will get their translation print-ready without them needing to tell us; however, we default to not getting a document print-ready unless the client specifically wants us to. It’s a cost-saving measure for the client. We have learned, though, to talk to the client about this issue, educating them, if necessary, about the differences between desktop publishing and basic quality assurance (we also cover these differences below), and establishing clear goals for the end result.

Desktop Publishing and the Issue of Page Match

We also commonly encounter the issue of page match: should a translated document have the same content on the same page number as the original, and should the translated version be exactly as long. This becomes especially thorny when a target language expands or contracts (they usually expand) significantly in relation to English. A Spanish translation, for instance, will wind up being considerably longer than its English original. What to do if the client wants a page match? We can decrease line spacing. Or the font. In extreme cases, there are other measures. We rarely resort to them, however, as they risk making a final version too visually distinct from the original.

Illustrations and other non-linguistic elements, too, are not exempt from confusion. An infographic in the original may be split across two facing pages, for example, but the customer expects us to consolidate it to a single page. Or vice versa. They may want a caption added, or an existing caption removed. Or an existing caption left in the original. Or an existing caption left in the original with a translated copy below it. Or, …well, you get the point.

Quality Assurance? Desktop Publishing? What’s the Difference?

I’ve been using these two terms a lot, and I suppose I should clarify what they mean. If you already know, you can skip this paragraph.

Quality assurance is a basic process that we perform on every translation that comes through our company. It involves a side-by-side comparison of the translated text to the original. When carrying out our quality assurance protocols, we match text blocks and spacing, punctuation, callouts (elements such as pull-quotes, boxes, bullets, arrows, etc), page numbers, and other key elements. Essentially, in quality assurance, we ensure the translation matches the original. Not so much in terms of the actual language — a professional proofreader will already have done that check. Though quality assurance is less involved than desktop publishing, the process does demand attention to detail on the part of our QA specialists.

Desktop publishing, in contrast, is a much more thorough process and encompasses all of the elements we have already discussed in this article. This is a value-added service that we provide when a client needs it. And, as I mentioned above, desktop publishing demands that a project be ready for the printer. Besides the obvious QA concerns, DTP entails layout, typographic alignment, correct file type, and much more.

It’s all about the satisfied translation customer

My team, and the role we play in U.S. Translation Company, are crucial to our firm’s ongoing reputation for uncompromising quality. Along with our top-tier project managers (see Kathy Sprouse’s post, “Making the Clients Happy,” as well as that of Austin Becker, “Not Your Grandfather’s Translation“), we ensure that our clients experience the very best. And, when the unexpected occurs, we find a way to make it work.