The translation of technical documentation is often seen as the final stage: the manufacturer has already prepared the instructions, drawings, specifications and tables, and now these materials need to be translated into another language. In practice, it is the word ‘simply’ that causes the most problems here.
A technical document is not an ordinary text. It is read not for the sake of information per se, but to carry out a specific action: assemble equipment, connect a system, perform maintenance, find the right part, check for an error, or follow a safety procedure. Therefore, every term, designation, reference to a diagram, or button label must function not in isolation, but as part of a single system.
This is precisely why a high-quality technical translation begins even before the first sentence is translated. It is necessary to understand what source materials are available, whether any previous translations exist, how the diagrams are formatted, in what format the drawings are saved, whether there is corporate terminology, who will be using the documentation, and what the final file should look like.
For a manufacturing or import company, this is no mere formality. The preparation stage determines how quickly the translation will proceed, how many clarifications will be required, whether the layout will need to be revised and, most importantly, whether the finished document will actually be fit for purpose.
Why technical translation begins even before the translator starts work
An operating manual, service manual, equipment specification sheet or set of installation documents rarely consists solely of paragraphs of text. They usually contain tables, drawings, specifications, formulae, part numbers, warning blocks, notes, references to figures and internal numbering. Often, the same term appears in several places at once: in the text, on a diagram, in the spare parts list and on the equipment’s own interface.
For this reason, the translation cannot be treated as a collection of independent phrases.
Let’s take an instruction manual for an industrial compressor as an example. The text mentions a ‘pressure relief valve’; in the specification, this component has a separate part number, whilst on the diagram it is labeled as ‘V12’. If, in the main text, it is translated as ‘safety valve’, in the table as ‘pressure relief valve’, and remains in English on the diagram, the document would not technically be incorrect. However, the user will have to check each time whether the same component is being referred to.
In documentation running to several hundred pages, such minor differences add up. And at some point, the problem is no longer one of style but of the document becoming more difficult for the reader to work with.
Another important factor is the purpose of the material. An end-user manual must be clear and practical. A service manual must be precise and professional. Installation documentation must correspond as closely as possible to diagrams and designations. An equipment catalog, on the other hand, can combine technical precision with a more marketing-oriented presentation.
It is therefore important to determine, before starting work, who will be reading the translation and for what purpose.
The format of the source materials is no less important. A Word document with editable text, a PDF with a text layer, a scanned PDF, and a DWG file may all contain the same content, but from a workflow perspective, they present different challenges. In the first case, the text is easy to edit. In the second, it can be edited to some extent. In the third, the content must be reconstructed first. In the fourth, the translation can be integrated directly into the drawing.
That is precisely why a brief audit of the documentation is the right way to start. It allows you to assess the full scope of work before the project has already ‘gone into translation’.
What materials should be provided alongside the document?
One of the most common situations is when a client sends a single PDF and expects that to be sufficient. For a short instruction manual, this might work. For complex equipment, however, it is not always the case.
The translator sees the words, but does not always see the product.
For example, the name of a component may have several correct equivalents, and only the manufacturer’s catalog or a photo of the equipment shows exactly what is being referred to. Or an abbreviation that seems standard is actually an internal code specific to a particular company. Without context, the translator is forced to spend time searching or making assumptions.
It is therefore useful to provide, alongside the main document, any materials that help to understand the product: catalogs, specifications, datasheets, previous instructions, drawings, technical presentations, links to the manufacturer’s website, and videos showing the equipment in operation.
Older translations are particularly valuable.
Even if they are not perfect, they demonstrate the terminology the company has already become accustomed to. For example, the after-sales service team may have been using a particular name for a component for several years. If a new translation suddenly introduces a different term — one that is technically correct but unfamiliar to staff — this may cause more problems than it solves.
Therefore, previous materials should be viewed not as ‘old files’, but as the company’s terminological history.
Another important resource is documentation for related equipment. A manufacturer may use the same terms across different models, which helps see the naming system as a whole rather than just an isolated word in a single sentence.
For equipment with displays or software, it is useful to provide screenshots of the interface. If the manual says ‘press the Start Cycle button’, but the screen shows ‘START CYCLE’, the translation must take this into account. Otherwise, the Ukrainian text may be correct but disconnected from the operator’s actual workflow.
A glossary as a working tool, not a formality
In technical translation, by no means all problems relate to complex terms. More often, difficulty arises when a single term can be translated in several ways.
For example, ‘housing’, depending on the design, can be a casing, a cover or a shell. ‘Drive’ can mean a drive unit, a drive mechanism or a drive module. ‘Seal’ can mean a seal, a sleeve, a gasket or a sealant.
If each term is considered solely within a specific sentence, individual choices may be correct. However, a technical document has another requirement: consistency.
This is precisely why a glossary is needed.
Essentially, it is an agreed-upon database of terms that records the key names of parts, assemblies, processes, modes, materials, interface commands, abbreviations, and service designations.
A glossary is particularly valuable in large-scale projects. If several specialists are working on a translation, without a shared database each may choose their own ‘correct’ variant. The editor then spends hours standardizing the terminology.
If the rules are agreed upon at the outset, a significant proportion of such problems do not arise.
A good glossary contains more than just ‘word-for-word translations’. It may include notes such as: do not translate the product name; leave the code unchanged; use a specific name for one model only; retain the English interface name alongside the Ukrainian one.
In other words, it is no longer just a dictionary, but a set of working solutions for a specific project.
What to do if there is no glossary
The lack of a ready-made terminology database should not hold a project back. In fact, many companies do not have a separate glossary at all.
Terms may be scattered across dozens of files: some in technical catalogs, some in old manuals, some in Excel spreadsheets, and some exist only in the engineers’ spoken language.
In such a situation, a glossary can be created during the very first translation.
The translator or editor identifies frequently repeated or ambiguous terms, suggests basic equivalents, and compiles a list of questions. The client does not need to check through hundreds of pages; it is sufficient to agree on a few dozen key decisions.
This is an important difference.
Instead of a request to ‘check the translation’, the technical specialist receives a specific question: which version of this component’s name is used in your company? Should this abbreviation be translated? Should we leave the English command on the screen?
Such questions are resolved much more quickly.
Once the first project is complete, a baseline already exists. The next instruction manual, catalog, or service manual does not start from scratch. Some decisions are automatically carried forward.
For an importer who regularly works with a single brand, this can have a significant economic impact: fewer approvals, fewer editorial corrections, and a faster launch of subsequent projects.
AutoCAD, PDF and drawings: file format matters
For technical documentation, format is sometimes more important than page count.
Ten complex drawings as scans may take longer to process than a 100-page Word manual. The reason is simple: the text must not only be translated, but also located, restored, linked to graphic elements and correctly reintegrated into the document.
The most convenient option is source files edited in a drawing program, such as DWG or DXF. In these, text elements can be modified directly within the drawing structure, whilst retaining annotations, positions and links.
With PDFs, the situation is more complicated.
If the file has been exported from AutoCAD or another program and contains a text layer, it is fairly straightforward to work with. If it is a scan, the text becomes part of the image.
For large sets of drawings, this has a significant impact on cost and turnaround times.
It is therefore worth checking at the outset whether the manufacturer has the source files. Sometimes the importer only receives a PDF, but the DWG can be requested separately. A single email to the manufacturer at the start can save a great deal of manual work later on.
A separate issue is exactly what to translate in the drawing. Not all text requires localization.
Part codes, item numbers, designations of electrical components or product codes often need to remain unchanged. The names of assemblies, notes, warnings and instructional captions, on the other hand, may require translation.
It is therefore advisable to first divide the elements into three groups: to be translated, to be left unchanged, and to be presented in both languages.
This is far more reliable than mechanically translating everything that resembles text.
Why text, tables and diagrams need to be checked together
Technical documentation works through interconnections.
The text refers to a figure. The figure refers to a part number. The part number refers to a specification. The specification contains a part code. The user orders a spare part using this code.
If even one of these links is broken, an error may manifest far beyond the translation.
For example, the text states: ‘Fit the filter at item 18’. After typesetting, the numbering in the diagram has changed, or the caption has accidentally moved. The sentence has been translated correctly, but the instruction no longer directs the user to the correct component.
Therefore, the final check must cover not only the language but also the document’s internal logic.
This is particularly true of multi-page manuals containing dozens of cross-references. After translation, the text volume changes; pages may shift, and tables may expand. If the references are linked manually, they require separate checking.
Another point to bear in mind is the equipment’s interface.
It is not always necessary to translate a command in such a way that the original disappears completely. If a user physically sees ‘EMERGENCY STOP’ on a button but reads only ‘Emergency stop’ in the manual, they must determine for themselves that they are the same.
In such cases, it is better to phrase the instruction in a way that helps the user navigate the actual equipment.
Layout is part of technical translation.
Clients often assess the scope of a project by word count. For technical documentation, this is not enough.
If a file has a complex structure, part of the work begins only after the translation is complete.
The Ukrainian text may be longer than the English version. As a result, captions may not fit within their blocks, tables may expand, warnings may spill over onto the next page, and illustrations may become misaligned.
In documentation comprising just a few pages, this is easy to correct manually. In a large manual, however, such changes may need to be made hundreds of times.
Therefore, the format of the final document must be agreed upon before work begins.
If only a translation of the text is required for internal use, there is no point in spending time on a complete reproduction of the design. If, on the other hand, the manual is to be distributed to customers or fitters, the structure and visual consistency may be of paramount importance.
For some companies, Word will be the best solution. For others, a final PDF. If the documentation is updated regularly, it is advisable to keep an edited version so that subsequent changes do not have to be made again.
This should be discussed in advance, rather than after the translation has been completed.
Who should answer technical questions?
Even a well-organized project cannot rule out the need for clarifications.
This is particularly true if the equipment is highly specialized or the company uses its own terminology.
Ideally, there should be a single point of contact on the client’s side to whom technical questions can be addressed. This does not necessarily have to be a manager or someone who speaks a foreign language. It is more important that they have a good understanding of the product.
This could be an engineer, a process engineer, or a service specialist.
However, an effective approach does not involve this person proofreading the entire translation.
The agency’s task is to review the documentation independently and raise only those questions where knowledge of the internal context is essential.
A short table format works well, listing ambiguous terms, a snippet of context, and a suggested translation. The client quickly confirms the decision, after which it is recorded in the glossary.
This approach is far better than endless correspondence over a single term.
How to handle a large set of documentation without chaos
A particular challenge with large projects is not the translation itself, but file management.
Manufacturing companies often have several versions of a single instruction manual, individual drawings, additions to specifications, new pages, and revised diagrams. If all this arrives on different days via different channels, the risk of mixing up versions increases very quickly.
It is therefore advisable to submit materials in a structured manner.
For example, a separate folder for source documentation, another for references, and another for drawings. If there are several versions of a file, it is advisable to mark which one is the current version clearly.
For large projects, it is also useful to set priorities.
There is no need to wait for all 800 pages to be translated if the installation team only needs 70 in a week. The project can be divided into stages: first, the installation documentation; then, the camera operator’s documentation; and finally, the maintenance documentation.
This allows the business to make use of the results even before the entire project is completed.
Checklist before handing over documentation
Before starting, it is worth checking a few things: exactly which files need translating; whether there are editable source files; whether diagrams and graphics need to be worked on; whether any old translations exist; what format the output should be in; who will be using the document; and who within the company will be able to answer technical questions.
It is also advisable to specify any critical deadlines straight away. If some of the materials are required earlier, it is best to take this into account during the planning stage.
If it is unclear exactly which files should be submitted, or whether a PDF is sufficient, there is no need to reorganize the entire set yourself.
You can show the materials to our specialists first.
At the STATUS KO Translation Center, we can carry out a preliminary assessment of the structure of the technical documentation, file formats, the complexity of diagrams, and the need to work with AutoCAD, layout, and terminology. Following this, we can determine the optimal translation process, the final output format, and the approximate scope of any additional work.
For a manufacturing or import company, this means a predictable process even before work begins.
And this is perhaps the main difference between a translated file and professionally prepared technical documentation. In the latter case, the document not only sounds natural in another language but also remains a practical tool for those who will use it.
