» ISTCPublications and ResourcesArticlesA checklist for translation projects
Members: Time to renew your memberships. You can pay online (remember to log in first).

A checklist for translation projects

Maxwell Hoffmann shares a common-sense checklist for technical documentation translation projects.

This article was published originally in Communicator. Communicator is the authoritative, award winning, journal for UK technical communicators. It is home to high quality, objective, and peer-reviewed features – current, relevant, and in-depth.

Modern technical documentation requires us to “think globally” during the authoring process to anticipate language translation and localization. Do you translate your technical documentation? And if so, how long does it take? Since more organisations than ever depend upon global markets for revenues, all of us are being drawn into issues and efforts that can affect translation cost and quality.

Many of us in technical communications can remember days in the not-so-distant past when translation projects were treated as an afterthought: “Let’s make it available in Chinese, too!”

Think of your translation project as an intelligent effort to ensure that you have clear channels of communication into another language and culture. This loosely parallels the common sense that we use for optimising mobile and VoIP audio communications; we try to eliminate bandwidth and noise factors.

Over time, we have learned to move away from fluorescent light fixtures when attempting decent audio with some mobile devices. There are similar scenarios we can avoid when trying to achieve clear translation.

The intent of these guidelines

There are many, many checklists of various types to ensure good translation or even for selecting the language service provider (LSP) who is the best fit for your needs. Since I have worked in technical documentation and translation for several years, my guidelines are based on several common-sense precepts that are not followed as often as you might think.

Please note that these guidelines are based on my personal experience, and are not official guidelines from my employer.

A variety of factors can impede your success with a translation project: well-intended managers with unrealistic timelines; lack of sufficient communications among stakeholders in your organisation; lack of clear expectations and guidelines from you to your vendor … and much, much more.

The following guidelines assume that you are not an experienced translation professional but that you are familiar with most components of technical documentation projects.

  1. Understanding and communicating project scope

You cannot expect to get an accurate cost/time estimate from your LSP if you don’t know the full extent of your own project. If some of your assets are still in flux (for example, still being written), get a realistic handle on probable final word count, number and type of graphics, etc.


Figure 1. Scoping your project can be simple
This goal becomes more complex when you have to translate an older, legacy project that hasn’t been touched for several years. Don’t make assumptions about what version of software was used for file creation. File analysis and spot-checking are required on your part to determine if older files were created or authored in a substantially different way.

If you are submitting a project for an estimate from an LSP, submit some source files, if possible. If your LSP only has PDF output to make an estimate, much more guesswork will be involved.

  1. Layout and text expansion constraints

Text layout tends to be more fluid and less page-oriented in multi-channel publishing. However, you may have inherited a project that has specific page layout and page break requirements. An extreme example would be a parts catalogue in which product description and specification must fit on an even page, and the tables of part numbers and prices must fit on the following odd page.

Language translation usually produces text expansion. English translated into Dutch or German will often expand to about 38% more line breaks whereas English translated into Korean may have almost no text expansion. If your source English files have content that barely fits on the page, and expansion across the page break is forbidden, you and your translation vendor

Figure 2. Visualise the containers in your layout as rooms that only allow so much content
have very few corrective tools at your disposal. Basically, all that you can do to keep expanded, translated text onto one page is reduce point size, condense fonts, resort to kerning and reduce line-spacing. Needless to say, these tools can seriously impair content readability.

  1. The trouble with tables

Technical documentation is not as riddled with tables as it was 10–15 years ago. But tables persist. Basically, think of each table cell as a tiny page with layout and text expansion challenges. If your tables contain numeric, tabular data, your issues may be few. If descriptive text and graphics reside in table cells, the pain threshold of your translation project can escalate very quickly.

Figure 3. Text expansion will cause tables to seem smaller in terms of content fit
Your LSP will have a handful of formatting choices to squeeze expanded tables onto one page, to match your source language. The best practice is to anticipate possible text expansion in your source files as tables are authored. If a table must fit on a translated page, make sure that there is at least 30% white space between the bottom of the table and the page end.

Avoid the following practices in tables at all costs:

  • Rotated text in header rows
  • Nested lists
  • Indented paragraph formats
  • Automatic text prefixes (for example, “Example:”) which may expand to more than two characters in a target language.

All of these practices wreak havoc with tables when text expansion occurs.

Does it need to be in a table?

If you must translate an aging legacy document with lots of tables, revisit whether all of the information needs to be in a table. Once tables became easier to create and manage in traditional DTP authoring tools 20 years ago, some writers fell into a “fad” of using tables whenever possible.

You may find that many tables are not really data or category oriented at all. Sometimes nested lists or hanging indents will achieve appropriate emphasis.

  1. Character-level trauma zones

If your technical publications are effectively authored with structured content and reusable components (for example, DITA), your formatting should be virtually automatic. Format overrides are possible, but in a much more constrained and sensible manner.

This guideline focuses on projects destined for print that use traditional, unstructured file formats (Word, FrameMaker, and so on). In these files the author has the latitude to reformat text and override format styles on an “as-wanted” basis.

Source document files in non-structured formats often contain sub-paragraph level “gotchas” wherein an author or editor tried to manually fix presentation. Common troublesome format overrides include manual page breaks, line breaks and hard spaces. Hard spaces are often used to keep two words next to each other; this may not be appropriate after the text is translated. Hidden codes may also be present to override or prevent hyphenation on a word-by-word basis.

  1. A graphic challenge

Embedded videos and dynamic graphics in on-line files have helped to eliminate many of the headaches associated with sequential screen captures. Traditional technical illustrations for print documentation have not become extinct, so we will focus on one type of visual element.

There are so many linguistic issues with translated graphics, that we could easily devote a three-part series to this one project element. The two biggest issues with graphics are: (a) “lost” graphics source files and (b) editable text in graphics. (Note: this section does not deal with screen captures.)

It is much more expensive to alter call-outs and labels in bitmapped graphics vs. vector files that have accessible text layers.

The majority of technical illustrations are probably created with Adobe Illustrator or Adobe Photoshop. Both of these programs have a great deal of versatility with text presentation and layout. Unfortunately, many graphic artists in the past did not archive or save the native source file format. Once a project was complete, some artists saved the derivative JPEG file and discarded the original, editable source file.

This adds considerable expense to a translation project because someone on the LSP staff must take extra steps to reach and edit the text layer. In some instances, Illustrator graphics have “words” that have been converted to vectors.

Text expansion within graphics

Text callouts within a technical diagram can often require a line break to accommodate text expansion. Obviously, this can cause problems if a short part number is tucked between two visual elements in a diagram, wherein there is no room for a second line of text.

An old but useful solution is to use “keyed callouts”. Place numbered arrows in the diagram and insert the callout text in corresponding numbered table rows below the illustration. When translation causes text expansion in the target language, text can “wrap” in the table cells; you will have no issues with text wrap obscuring part of the diagram.

  1. Setting realistic project expectations

This is important in terms of expectations with your LSP as well as with your internal stakeholders. In today’s “agile” environment, we seldom have static, complete content before embarking on a translation project.

Since your translation budget and projects will nearly always be based on an intelligent estimate, try to realistically “pad” your project timelines and costs to account for the unexpected. Translation challenges vary widely from one type of project to another. If you have done translation projects before, you should have some sense of common timeline delays.

Your LSP will be able to advise you of issues that can affect schedule and cost. For instance, if you are translating into Arabic, Farsi or other mid-East languages, most of the linguists will likely have a business week that starts on Sunday and ends on Thursday. If you let a project component sit on your desktop for a couple of days and send it out Thursday morning for analysis, you’ve just lost an extra business day.

  1. Does it need to be translated?

I deliberately saved this question to the end. Obviously, this should be the first question asked. However, you would be surprised how many times this question is not asked until after a large-scale project is translated for the first time. Many factors determine whether a project should be translated, for instance, is there still an audience in a particular locale for a project created 10 years ago?

I have personally been involved in Linguistic Quality Assurance and corrective DTP for over a dozen “gnarly” projects that ultimately proved to have no audience. This seems to be incredibly obvious, but it is not. Corporate staff is much more transient than in decades past, so much of the “tribal knowledge” that would help you quickly discern whether a project is worthy of translation is no longer present. As a result, we are paying the price in other ways.

Never be afraid to ask this question. Besides avoiding a raft of headaches, it can obviously save your organisation a lot of money.

Maxwell Hoffmann is a Digital Marketing / Content Strategist based in Portland, Oregon

W: https://www.linkedin.com/in/maxwellhoffmann/