How to Translate Supplier and Vendor Documentation Without a Translation Department

A procurement lead wrote to us in March with a problem we now recognise on sight. The company had just signed with a machine supplier in Turkey. The supplier sent 180 pages of documentation, all of it Turkish, and the maintenance crew needed the commissioning section before the line went live in eleven days. Nobody in the building read Turkish. That is usually the moment a company discovers it needs to translate supplier documentation and has no idea who owns that job.

Most companies never plan for this. There is no translation department, no line in the budget, and no process. What there is, instead, is a deadline and a pile of files in a language the team cannot check. We have watched enough of these situations to have opinions about which parts are actually hard and which parts people only think are hard.

What supplier and vendor documentation actually contains

The word "documentation" hides how varied this material is, and the variety is what makes the job awkward.

A typical supplier package for an industrial buyer includes an installation and operating manual, usually a long DOCX or a PDF exported from one. Alongside it come parts registers and price lists as XLSX workbooks, sometimes with several sheets and a column of part numbers that must survive untouched. There are training slides in PPTX, prepared by the vendor's application engineers. There are certificates: declarations of conformity, material certificates, calibration records. And there is a service agreement, which is a legal document wearing the same folder as the rest.

These are not one job. They are four or five jobs with different requirements that happen to arrive in one email.

The manual is long, repetitive, and full of tables, numbered warnings, and figure captions that point at diagrams. Getting the words right matters less than getting every warning and every table cell to survive in the same position. The parts register has almost no prose at all, and translating the wrong cell in it causes a procurement error rather than a comprehension error. The training deck has short text in shapes that will overflow if the target language runs longer, which German and Russian reliably do. The certificate may need to be a certified translation with a translator's stamp, and no amount of software will produce that.

One buyer we worked with sent all of it into the same process at the same quality level and paid for the manual twice: once for the translation, once for the rework after the maintenance team found that torque values had been reformatted into a different decimal convention. Sorting the pile first would have taken an hour.

Why the usual shortcuts fail when you translate supplier documentation

Everyone tries the same three things first, and each fails in a specific, predictable way.

Pasting the text into a chat window works for a paragraph and falls apart on a manual. The formatting is gone the moment you copy, so somebody spends a day rebuilding tables. Worse, long pastes get truncated silently. We have seen a 40-page section come back missing its middle because the person doing the pasting had no way to notice that six pages had quietly vanished. There is no error message for content that simply did not arrive.

Free browser-based document translators keep more of the layout but introduce two other problems. Layout still breaks on anything structurally interesting: merged cells, multi-level numbered lists, text boxes anchored to figures. And the confidentiality question is real. A supplier agreement with pricing in it should not go through a service whose terms permit retaining your text. We have written about whether free tools are safe for confidential documents elsewhere; the short version is that the answer varies a great deal by provider and is rarely what people assume.

The third shortcut is asking the colleague in sales who speaks the language. This one is the most expensive and the least visible on any budget. Speaking a language is not the same skill as translating a technical manual, and the colleague usually knows this even if nobody else does. They will do it slowly, resentfully, and with no terminology consistency between the section they did on Tuesday and the section they did on Friday. Meanwhile their actual job stops. If you are going to spend a person-week of internal time, spend it on review rather than on production.

Sort the documents by what an error would cost

Before anything gets translated, sort. This is the step that changes the economics of the whole exercise, and it takes less than an hour for a typical supplier package.

Put every document into one of four groups.

Legally binding. Service agreements, warranty terms, anything that creates obligations. These need a professional human translator, and sometimes a certified one. Do not automate this group. The cost of a misunderstood indemnity clause is not comparable to the cost of a translation.

Safety-critical. Operating instructions, warnings, lockout procedures, anything a person follows while standing next to a machine. These can be translated with AI, but they need a named internal reviewer who knows the equipment and signs off on the warnings specifically. Numbers, units, and negations get special attention, because "do not" losing its negation is the failure mode that actually hurts people.

Operational. Maintenance schedules, parts registers, configuration guides, training material. This is the bulk of the volume and the group where an automated workflow pays for itself. Errors here cost time, not safety.

Informational. Company overviews, product brochures, background material the vendor included out of habit. Translate it cheaply or not at all. We regularly tell companies to skip a third of what a supplier sends, and nobody has ever complained.

The point of the sort is not bureaucracy. It is that a 180-page package is rarely 180 pages of equal risk. In the Turkish case above, the legally binding group was six pages, the safety-critical group was about twenty, and everything else was operational. Six pages to a certified translator is an affordable invoice. One hundred and eighty is not.

A workflow a non-linguist can actually run

Once the pile is sorted, the operational group follows a sequence that someone in procurement or engineering can own without any language training.

Start by asking the supplier for editable source files. This single request saves more downstream effort than anything else on the list. Suppliers usually have the DOCX or the XLSX and send the PDF because PDF feels more official. A PDF has to be reconstructed before it can be translated, and reconstruction introduces errors that were never in the original. Ask, and about half the time you get the real file.

Second, build a short terminology list before translation starts, not after. Twenty to fifty terms is enough: your internal name for each machine, the part-number prefixes that must never be altered, the units you standardise on, and the handful of terms your engineers already argue about. Pull them from documents you already have in both languages, or from the supplier's own website if it publishes in more than one language. A glossary that fits on one screen prevents most of the inconsistency that makes a translated manual feel untrustworthy.

Third, run the translation with something that keeps document structure intact rather than something that produces a wall of text. The test is simple: open the output and check that table row 47 is still table row 47.

Fourth, route the result to an internal subject-matter expert. Not for language. For plausibility. A maintenance supervisor who does not speak Turkish can still tell you that a stated clearance of 0.3 mm is wrong because it has always been 3 mm on that model. This review catches a category of error that no linguist would catch, and it is the reason internal review beats external review for equipment documentation.

Fifth, keep a bilingual version of the file, with source and target side by side. You will want it in eight months when the supplier issues a revision.

How to check quality when nobody on your team reads the language

This is the question that stops most companies from trusting any translation process, automated or human. You cannot evaluate what you cannot read, and the discomfort is reasonable.

Three checks together get you to a defensible level of confidence.

The first is structural completeness. Compare segment counts, table counts, and page counts between source and target. Untranslated segments and dropped content are the most common failures in automated document translation, and both are detectable without knowing a word of the language. Anything that came out identical to the source deserves a look: sometimes it is a part number that correctly stayed put, sometimes it is a paragraph the system skipped.

The second is a QA report. A structured report on the translated output flags terminology that diverged from your glossary, numbers that changed between source and target, missing or altered formatting, and segments the system itself rated as low confidence. This is not the same as knowing the translation reads well, and we would not claim otherwise. It does tell you where to look, which is what a non-speaker actually needs. We go into more depth on this in our piece on checking translation quality when nobody on your team speaks the language.

The third is targeted human review. Take the safety-critical group, plus a random 5% of the operational group, and send it to a professional reviewer in that language pair. A few hours of review across a sample tells you whether the whole output is sound. If the sample comes back clean, the rest almost certainly is. If it comes back with systematic problems, you have found them for the price of a few hours rather than a full re-translation.

Back-translation, where the target text is translated back into your language, is popular with managers and less useful than it looks. It reliably catches inverted meaning and dropped negations. It also generates false alarms on every legitimate rephrasing, and teams burn hours investigating them. Use it on the warnings. Do not use it on the manual.

Documents that get revised every few months

Supplier documentation is not a one-time job, which most companies discover on the second revision. The vendor ships firmware 2.4, and forty pages of the manual change.

Two habits make revisions cheap. Keep the glossary as a living file rather than something you rebuild each time, so the terminology you settled on in version 1 carries into version 2 without renegotiation. And keep the bilingual export from the previous round, so you can identify what actually changed instead of re-translating the whole document. A comparison between the old source and the new source usually reveals that most of the content is untouched.

We have seen companies re-translate a full 200-page manual four times in two years because nobody kept the previous output in a form that could be compared. That is the most common avoidable cost in this whole area, and it comes from filing habits rather than from any tooling decision.

Where this approach stops working

Being honest about the limits matters more than being encouraging about the possibilities.

An automated workflow does not produce certified or sworn translations. If a customs authority, a court, or a notary needs the document, you need a translator whose credentials attach to it, and no software substitutes for that.

It does not handle scanned documents well without an extraction step first, and extraction from a scan of a fax of a photocopy will fail regardless of how good the translation engine is.

It does not replace a domain expert for regulatory submissions. Medical device documentation, pharmaceutical material, and anything going to a regulator has requirements that are about traceability and accountability, not only about accuracy.

And it works considerably better between well-resourced language pairs than between rare ones. English and German is not the same problem as Finnish and Vietnamese, and anyone who tells you otherwise has not tried the second one.

For the operational bulk of supplier documentation, though, the honest position is that the technology handles it and the constraint has moved. The hard part is no longer producing the translation. It is deciding what needs which treatment, and building a review step you trust.

If you want a tool aimed at that operational group specifically, this is what we built SnapIntel for. You upload DOCX manuals, XLSX registers, or PPTX decks; the system prepares domain context and a glossary, runs the translation, and returns the translated file in its original structure together with a QA report and a quality rating. There is a one-time trial of 5,000 words over seven days with no card required, which is enough to put one real supplier document through and judge the output yourself rather than take our word for it. You can see how it works at snapintel.io.

What to do this week

Take the last supplier package that landed in your inbox and sort it into the four groups. Count the pages in each. In almost every case we have seen, the legally binding and safety-critical groups together are under 15% of the total volume, which means the expensive treatment applies to a small slice and the rest can run through a repeatable workflow.

Then pick one document from the operational group, ask the supplier for the editable source, write down twenty terms your engineers care about, and translate it. Have the person who maintains that equipment read the result for plausibility. You will learn more about whether this approach fits your company from that single document than from any amount of vendor evaluation.