Technical Translation

The defining features of this field are volume and repetition. The manuals for a product family are derivatives of one another, and the same warning sentence appears in hundreds of places. Technical translation is therefore not purely a language job but also an exercise in content management.

There is no consistency without a termbase

In a technical text, a part must be referred to by one and the same name throughout. Calling the same component a “bearing” on one page and a “roller bearing” on the next leads service staff to order the wrong part. The way to guard against that is to build a termbase, agreed with the client, at the start of the job.

A termbase is also a corporate asset. When a company changes supplier, the list goes with it and the new team carries on speaking the same language. Stating in the contract that ownership of the termbase and the translation memory rests with the client heads off a dependency that would otherwise become expensive later on.

File formats and page layout

Technical documents rarely arrive as plain text. Labels placed on drawings, tables, automatically generated contents lists and cross-references make the formatting side of the translation part of the job proper. Text expanding in the target language creates the problem of copy that no longer fits fixed-width boxes.

Safety warnings are a category of their own

Warning text in a manual cannot be treated like ordinary explanatory prose. The headings that signal the level of hazard, the order in which those headings appear and the sentence structure of the warning itself are in many cases defined in the relevant standards. The translator’s latitude here is minimal; what is called for is the established wording of the target language.

In the same way, units of measurement, tolerance values and model codes are untouchable in translation. “Localising” a screw size or a voltage rating is a serious error; these values are carried over exactly as they appear in the source.

The exception is purely presentational matters such as the decimal separator. These may be adapted to the writing conventions of the target language; but if they are adapted, they must be consistent throughout the document. Using two different decimal notations in the same table damages the credibility of a technical document outright.

How an instruction is built

Most of a technical text consists of instructions, and the instruction sentence has a grammar of its own. An effective instruction is short, covers a single action and is in the imperative. Where the source has a long, nested sentence, leaving it in the same shape in the target language is not fidelity but a loss of usability.

Conditions, likewise, are placed ahead of the action: with the condition first and the action second, the reader will not carry out the step in the wrong order. Rendering temporal conjunctions correctly is another critical checkpoint; the difference between “after the operation is complete” and “while the operation is running” can have safety consequences in the field.

The third principle is uniformity. In literary writing, synonyms count as richness; in a technical text they are a fault. The same action is described with the same verb every time. This both lightens the reader’s load and improves the yield of the translation memory.

The role of the source text in multilingual projects

When a manual is going into ten languages, the quality of the source text becomes the largest single determinant of cost. Every ambiguity in the source turns into ten separate questions from ten separate translators, each of them answered separately. Preparing the source text for translation is therefore a saving, not an expense.

That preparation consists of three tasks: writing out ambiguous pronouns explicitly, using a single term for a single concept, and simplifying culture-specific examples. Made once in the source, these three corrections pay off across all ten languages at the same time.

The second determinant in multilingual projects is query management. Questions from translators need to be collected in a single list and the answers distributed to every language at once. Otherwise the same ambiguity is resolved differently in each language, and ten manuals end up saying ten different things. At the end of the project, that list is also the most valuable input for the next version of the source text.

The third element is releasing the languages one after another rather than all together. Publishing each language as it becomes ready, instead of waiting for all of them to finish at once, speeds up feedback and prevents the same error being repeated in the languages that follow. A correction that emerges in the source text can be carried across at no cost to the languages not yet started.

The steps in the process

1. The files are analysed; total volume, the proportion of repetition and any previously translated sections are reported.
2. A term list is drawn up and submitted to the client’s technical team for approval.
3. The translation is carried out by a translator who knows the subject area; a query list is kept for anything unclear.
4. Technical check: numerical values, model codes, cross-references and warning text are verified.
5. The page layout is rebuilt; overrunning text, broken tables and truncated labels are corrected.
6. A final visual check is made, and the work is delivered to the client with the translation memory updated.

What determines the price?

The most widely misunderstood point in technical translation is that word count alone does not indicate the cost. In a family of manuals running to a thousand pages, a substantial part of the text may be repeated; the analysis report shows that repetition, and repeated sections are priced on a different band. A buyer who does not ask for an analysis report is paying full price for content they already own.

The second item is the page layout work, which is assessed separately from the translation fee. The third is the number of languages: in projects where the same source text goes into many languages, the preparation cost is incurred once and the cost per language falls. You will find the languages we work in on the language pages and the logic behind our pricing on the pricing page.

Situations that come up often

• The source text is itself unclear. Technical documents are often written in a hurry. A good translator reports these ambiguities in a query list, and that list amounts to a free quality audit for the client.
• The manual is updated later. If version differences are not managed, the same content is paid for twice. In updates, only the sections that have changed should be processed.
• Text inside images. When copy embedded in a figure is not exported, the translation is left incomplete, and this is usually noticed last of all.
• Files with machine translation mixed in. Files the client has had pre-translated cannot be priced until it has been clearly established whether they need correcting or retranslating. You can send us your files through the quote form.