As a tech writer, I’m sometimes called upon to manage documentation translation. While I can hold my own conversationally in a couple of second languages, I don’t speak the full range of target languages often required by many clients, so I have to trust my translators to do a good job. But not speaking the lingo isn’t a reason to treat the translation process as a black box. If you’re in charge of a translation project where you don’t speak the language, here are a few things you can do to facilitate the translation process, and validate what comes back.
First things first: Translation or localisation?
Be clear whether you’re looking for translation or localisation when you approach your vendor. Translation is purely moving from one language to another. Localisation involves additionally customising the content in the target language to match the culture/understanding of your intended audience – for example, changing people/place names to ones that sound more local, or changing financial examples to use applicable currencies and values. Be clear which you expect when you engage a vendor, and appreciate there may be considerable additional work in localisation.
Some checklists
Before translation, make sure you’ve made some key decisions and assembled supporting assets. Set your translators up for success.
- Untranslatable content: First things first, note any specifics that shouldn’t be translated. For example, your product name probably stays the same in all languages. If it includes a standard noun, there’s a risk that could be translated. Consider using a variable placeholder if your authoring tool supports it, so that unintentional translations can be quickly reversed.
- Software labels: If your docs refer to interface/GUI elements, then these should be translated, reviewed (ideally in situ) and approved before your docs go to translation. If the same translators are handling your interface and docs translations, feed back any new/changed strings before the docs translation starts. Document what changes were made and why. Examples:
- Was the context of a word missed? For example, “No” translated as “not yes” instead of “number”.
- Did the translation not fit? For example, maybe it overlapped another GUI element by 2 characters on one screen. In this case, the developers might choose to truncate the string everywhere it’s used, or create a second resource so that they can have long and short versions in different contexts. If there will be multiple valid translations, the translators should carefully check the screen context when translating the docs.
- Did an English label change at the eleventh hour, and internal SMEs provided the updated translations for the product build? In this case, the translators won’t have those string pairs in their translation memory – you need to let them know they exist.
- Hardware labels: If your docs refer to hardware labels, will these be translated or will the original labelling apply in all markets (e.g. “LIVE”, “GND” and “N” wiring labels on a PCB)? If the original labelling will be retained, make sure your translators know to keep those values in the text, possibly with indicative translations in brackets where it would aid the reader.
- Images: If your docs include graphics/screenshots, decide whether these should be translated too.
- If you want full text in the diagrams, make sure to create and save them in an editable format to pass along to your translators (e.g. Adobe Illustrator instead of gif).
- For schematics, simple flow diagrams, etc., it may be possible to simplify things by labelling your diagrams with a key such as A, B, C, and adding the relevant text in a bullet list or table below/beside the graphic.
- For GUIs, let your translators know if you’ll produce translated screenshots or not, or if they should do it. If they should do it, agree whether they’ll photoshop the result, or take an actual screenshot. If an actual screenshot is to be used, make sure to provide them with working software and the steps/data required to see the screen(s) in question.
- If you decide not to translate screenshots, the text should use the translated GUI labels if they’ll exist, as the reader will most likely be working in the GUI for their language. You should make a call on whether it will be helpful to your audience to include the original (screenshot) label in the text as supplementary info every time, or only in certain contexts. For example, when translating “if a record already exists for that user, the Name field will be outlined in red when you click Save, as shown in the example above”, you might simply translate “Save” but include both the translation and original labels for “Name“. Agree how to communicate to your translator which specific strings/instances should be treated this way – for example, by adding notes to a PDF of the final original document.
- Native speaker input: Enlist support – find allies in your organisation who speak the language(s) you’re translating to, ideally natively. If they have experience of previous translation projects, or have ever been on the receiving end of translated documentation (we all have!), ask them for a few bullet points on what they’ve loved/hated, and record their feedback in a language-specific style guide. (I’ve written more on style guides here.)
After translation, without understanding a word of the target language it should be possible to check the following:
- Length check: Is the target document roughly the expected length. Some languages use more characters than others to express the same thing. If you’re translating to a language that typically uses 10% more characters than the source language, your target document should be roughly 10% longer. (Compare “real” page counts, excluding covers, copyright, TOCs etc. which shouldn’t change significantly.) If the translated doc should be 10% longer, but comes out 5% shorter or 40% longer, straight away you know something’s gone wrong. There’s a lovely table of expansion/contraction factors between English and a selection of other languages in this article.
- Spot check: Did any content escape translation? Skim the document, pick a small percentage of pages distributed evenly through the doc to check in more detail. Look out for whole paragraphs, or even individual words that have not been translated. If your authoring tool auto-injects any strings (for example “on page” in a cross reference), make sure the translated document uses translated versions of these strings too.
- Specific instruction check: If you provided any notes, for example on untranslatable names/labels, or long/short variants on different screens, check that specific requests appear to have been followed. Use the original doc as a guide for where to look.
- Image check: If images were supposed to be translated, check that they were. If you import your images by reference from a folder, you can tab through the resources there, which simplifies the job.
- GUI translations check: If you have translated GUI screenshots in your document, check that you see matching labels in the surrounding text (again, use your original document as a guide here). If they don’t, check the software to see which one is correct, and update the image or report the issue to your translators as appropriate. Spot check some translations that don’t appear with screenshots too, if possible.
- Completeness check: Run through the source and translated content side-by-side. Everywhere there’s a heading in the source, there should be an equivalent heading in the target (title, H1, H2, …); if there are 2 short paragraphs in the source, there should be 2 short paragraphs in the target; if there’s an image with a caption in the source, it should be there in the target too; if a source table has 10 rows and 3 columns, well, you can guess…
- Layout check: Because the length of sentences and paragraphs in the target language will differ from the original, you may see some unexpected page breaks or line breaks; in particular, watch out for headings/table cell contents wrapping in an unexpected way. If it’s under your control, make necessary tweaks, such as changing fixed table column widths; if you absolutely need something to be shorter than it is to fit, discuss with your translators how you could adapt the specific words or syntax of the translation to fit without loss of meaning.
- Native speaker check: When your translations come back, ask your allies (from above) to review/spot check what comes back against the original (set a page/time limit where content volumes are large, or identify specific pages/ranges if you’re dealing with an update rather than a new doc). Update your language-specific style guide accordingly. Your translators should take feedback on board in subsequent iterations/projects.
- Keep notes: If you need to fix/change anything, or if you encounter an issue not on this list, make notes for yourself and notes for your translators so that future projects go faster and smoother.
These lists are a starting point, but are by no means exhaustive. Different things will be more/less relevant depending on your specific industry/project/product. Any time an issue arises or a question is asked, consider adding an item to your checklist; if the question is asked more than once, stop considering and just add it!
