Translation Workflow for Manufacturers: How to Stop Managing Translations by Email and Spreadsheets
A translation workflow is the route a document takes from a request to a finished, approved file in every language you need. Most manufacturers still run it by email and spreadsheets, which costs more in coordination than in translation. A managed workflow gives you one request point, your own glossary and memory on every job, and clear status. DEMA Solutions runs that workflow for manufacturers.
Who this guide is for
This article is written for the people who keep multilingual documentation moving in a manufacturing company: technical documentation managers, technical writers, localisation managers, and the procurement and operations directors who sign off the suppliers and the budget. Most work at companies that build regulated equipment such as HVAC systems, lifting equipment, packaging machinery or automation lines. If you are weighing up software for this, our comparison of a translation management system and a managed workflow sets out when each one fits.
Their documents are manuals, spare parts catalogues, HMI strings, CE technical files, declarations of conformity, safety warnings and training material, in Word, InDesign, FrameMaker or DITA/XML. Many work inside an international group, where the parent wants consistent terminology and subsidiaries or distributors check every translation. Their questions are practical: why does every request become twenty emails, why do we pay again for last year’s sentences, and who has the latest version? The sections below take the translation process apart step by step.
What a translation workflow covers, end to end
When people say “translation”, they usually mean the moment a linguist turns one language into another. In a manufacturing company that moment is a small part of the job. The full translation workflow starts earlier and ends later.
It starts when a document needs to exist in another language: a machine ships to Poland, or a manual revision follows a design change. Someone collects the source files, decides languages and deadline and asks for a quote. The files are prepared, previous translations and approved terms are applied, new text is translated and revised, source questions are answered and the result is laid out again. Then come review by an engineer, subsidiary or distributor, corrections, final files, archiving and an invoice to check against the quote.
Every one of those steps has an owner, a handover and a place where it can stall. In a good workflow the handovers are defined once and repeat without effort. In an email workflow they are reinvented on every job, which is why translation workflow management is less about translation than about the steps around it.
Why email and spreadsheets stop working
In most manufacturing companies, translation requests come from the people who write the documentation: technical documentation managers and the technical writers responsible for the manuals. Purchasing or marketing order translations now and then, but most requests start in the technical office. The files usually travel by email, larger packages go through a company server, SharePoint or a file-transfer link, and the person who sends them also sets the deadline.
Email itself is not the problem. Most manufacturers still send their translation files that way, and for a single document it works well: a file goes out, a quote comes back, status sits in an inbox. The trouble appears when that pattern repeats for every manual, language and revision, across several people running their own threads.
Files go missing in long email threads. When a job is made of dozens of attachments, one is easily left out when the email is sent, or overlooked when the files are saved on the other side. Nobody notices until a chapter is missing from the translation.
Requests arrive from several departments. When the technical office, purchasing and marketing each order translations on their own, sometimes from different suppliers, nobody sees the total volume or can plan around it.
Every job starts from zero. Content translated for the last release is quoted again because the previous translations were not reused, or stayed with another supplier. The same warning in a family of ten machines can be paid for ten times.
Terms are decided again on every job. The same component gets one name in the manual, another on the HMI and a third in the spare parts catalogue. Service technicians notice first, then customers.
Versions drift. The source manual changes after the files have gone out. A corrected chapter is sent by email, a second correction follows, and at the end nobody is sure which version the German translation was based on.
Status means another email. Knowing whether a job is on track requires asking. A documentation manager who has to chase three suppliers before a shipment is doing project management by hand, and the time it takes is never on any budget.
The direct cost of an email-based translation workflow is rarely the translation itself. It is the hours spent coordinating, the rework caused by mismatched versions and inconsistent terms, and the risk of a missing language version holding up a CE-marked machine at the factory gate.
A single request point instead of parallel threads
The first change is also the simplest: one way in. All requests go through one person or one address on your side, and reach one contact on the supplier’s side. That contact should be a project manager who knows your products, your file types and your reviewers, so that a request does not need a fresh briefing every time.
A single entry point creates one place where volume, deadlines and languages are visible, and it makes urgent work manageable. When a late order closes and the shipping date does not move, there is an agreed route instead of a favour: who can declare a job urgent, what it needs and how quickly it is handled.
The request itself should be standard. Ten lines are usually enough: the files, the target languages and markets, the intended use (customer documentation, internal training, regulatory submission), the deadline, the reference material available, and who approves the result. A request written this way rarely needs a follow-up question, and the answer to “what did we ask for?” is always in one place.
File preparation: send the files your documents are built from
Most of the friction in a translation project comes from the files, not the language. A PDF has to be extracted, translated and rebuilt by hand, which costs time, introduces errors and leaves you a document that is hard to update. Send the editable source instead: the Word file, the InDesign package with links and fonts, the FrameMaker book, the DITA map or the XML export from your content management system. Only the text is translated, tags and structure are protected, and the file goes straight back into your authoring environment with no broken cross-references or lost conditional text.
Sometimes a PDF really is all that exists, typically for legacy manuals or supplier documentation. That is not a disaster, but it should be planned as a step rather than discovered as a surprise. The way we handle it is described in how DTP file preparation works: the document is rebuilt into an editable file once, so that every future revision can follow the normal route.
Two other habits save a great deal of rework at this stage. Mark what must never be translated (part numbers, software parameters, connector labels, product names) before the job starts, and tell the supplier which chapters changed since the last version. Both reduce the volume to translate and the chance of an error in text that should have stayed exactly as it was.
Source queries without the email ping-pong
Good linguists ask questions: a sentence can be read two ways, an abbreviation is unexplained, a value looks wrong. In an email workflow these queries arrive one by one and wait for a busy engineer, so the translation stalls, or the linguist guesses.
A managed workflow treats queries as part of the process. Questions from all languages are collected by the project manager, removed where the answer is already known from the glossary or previous jobs, and sent to you as one consolidated list with a clear deadline. The answers are recorded so that the same question is never asked twice, by any linguist, in any language. As a bonus, ambiguous sentences that confuse a translator often confuse a service technician too, so fixing them in the source improves every language at once.
Terminology and translation memory inside the workflow
Two language assets make the difference between a workflow that gets cheaper and faster over time and one that starts again on every job.
The first is the glossary: the approved term for each component, function and warning in every language, approved once by your engineers and subsidiaries and applied to every job, so the manual, HMI, parts catalogue and training material speak the same language. Our article on keeping technical terminology consistent across translators and suppliers explains how to build one and keep it current.
The second is the translation memory: every approved sentence stored with its translation, so identical or similar sentences are reused in the next document. For manuals that share text across a product family, this is where most of the long-term saving comes from, but only if the memory belongs to you, in a portable format you can take to any supplier. That question is covered in detail in who owns your translation memory.
These two assets are also what make translation workflow automation safe. Machine translation can speed up recurring technical content, but only when it is controlled by your approved terms and your previous translations, and followed by a qualified linguist who post-edits and checks the result. Where that approach works and where it does not is the subject of our guide to machine translation post-editing.
Review by subsidiaries and distributors without the bottleneck
In international groups, translations are often checked by people whose main job is something else, such as a service engineer at the German subsidiary or a sales manager at the Spanish distributor. Their knowledge is valuable; their availability is not guaranteed.
Three habits keep this review useful without letting it block the release. First, agree the scope: reviewers check technical accuracy and approved terminology, not personal style. Second, give every reviewer a deadline and a default: if no comments arrive by the agreed date, the translation is released. Third, send changes back into the workflow rather than into the file. When a reviewer prefers a different term, the change belongs in the glossary, approved once and applied everywhere, not typed into one PDF and forgotten.
As the glossary absorbs reviewers’ preferences, review rounds become shorter and subsidiaries learn to trust the terminology. For groups that work with several language suppliers in parallel, the same logic is explained in how enterprise organisations manage translation across multiple vendors and markets.
Version control and change management
Technical documentation is never finished. A design change, a new safety requirement or field feedback changes the source, and every language version has to follow. The principle is to translate changes, not documents: when a manual is revised, only new and modified sentences are translated, and the rest is recognised from the translation memory and stays exactly as approved.
It also requires discipline on your side. Freeze the source before it goes to translation, or agree how late changes will be handled. Give each source version an identifier and make sure every translated file carries the same one. And release all languages together where the documents are safety-relevant or part of a CE technical file, so that no market receives a manual that is one revision behind. A version log, kept by the project manager and shared with you, answers the question “which source was this translated from?” without searching through email.
Delivery back into your authoring tools
A translation is only finished when it is back in the format you publish from: Word files on the company template, InDesign documents that fit the layout, FrameMaker books that build without errors, and DITA or XML that validates and imports cleanly. Text expansion is the usual problem, because translated text often runs longer than the source while tables, callouts and HMI strings have fixed space. It has to be solved in the original files, not by shrinking the type until it is unreadable. This is the work of multilingual desktop publishing, and it belongs inside the workflow rather than after it. When layout is handled by the same team that handled the translation, a correction in one language does not trigger a new round of emails between two suppliers.
Status visibility and translation project management
Documentation managers do not need a dashboard for its own sake. They need to know, without asking, whether the Italian, German and French versions of a manual will be ready before the machine ships. That is the practical meaning of translation project management for the client: someone owns the schedule, flags risks early and reports status before you have to chase it. In practice that means a shared overview of open jobs, short status notes at agreed points and an early warning when late source changes or open queries put a deadline at risk.
Measuring cost, reuse and time
Operations and procurement directors ask a different question: are we paying the right amount, and is it going down as our content matures? The key figure is leverage: how much of each new job is already covered by your translation memory, fully or partly, and therefore charged at a lower rate or not at all. A simple example shows why it matters. Suppose a service manual of 40,000 words is revised and only 4,000 words are new or changed. With a working memory, the job is essentially a 4,000-word translation plus a check of the rest. Without one, it is quoted as 40,000 words again. Most of the difference in cost between suppliers comes from this, not from the rate per word. The other cost drivers specific to manuals are explained in the real cost drivers of technical manual translation.
Beyond leverage, four numbers tell you whether the workflow is healthy:
- Time from request to finished, laid-out document, not only translation time.
- Review rounds per document with your engineers, subsidiaries or distributors. Fewer rounds usually means better terminology.
- Reuse per release, which should grow as your memory grows.
- Internal hours spent coordinating, even as a rough monthly estimate.
If these figures do not improve over a few releases, the workflow is not doing its job, whoever runs it.
Do you need a translation management system?
Many teams researching how to improve their translation workflow come across translation management system software, and it is a reasonable option to consider. Software of this kind centralises requests, files, translation memory and status in one place. It works well for companies with a localisation department that can own it: configure it, maintain the connectors to authoring tools, train internal users and manage linguists or suppliers through it.
For most mid-size manufacturers the picture is different. Translation is handled by technical writers whose main job is the source documents, software brings a licence, a set-up project and an internal owner, and you still need linguists, revisers and DTP specialists. The alternative is a managed workflow, where a language partner runs the process and your teams send files and receive finished documents. The deciding factor is whether you have people whose job is to run translation, or people who need translation to run without them. If you are still weighing whether translation should stay inside the company at all, our comparison of translation outsourcing and in-house translation sets out where each model works and where it breaks.
Moving from today's process, step by step
You do not need to change everything at once. Manufacturers who make the move successfully usually follow a sequence.
Map what you have. List who requests translations, for which documents, languages and suppliers, and ask current suppliers to export your translation memories and glossaries in standard formats.
Set the entry point and the request template. Decide who sends requests on your side and agree the ten-line request.
Start with one document family. Run the manuals of one machine range with regular revisions through the new workflow first, with clean editable files and a glossary agreed with your engineers and main subsidiary reviewers.
Measure and extend. After two or three releases, compare the four numbers above with what you had before, then bring in the next product family, the HMI strings, the parts catalogue and the training material.
If you are also reviewing suppliers as part of this change, the criteria worth checking are set out in how to choose a technical translation company.
How DEMA Solutions runs the workflow for manufacturers
When a manufacturer works with us, you have one commercial contact, your sales manager, working closely with a dedicated project manager who knows your files, collects source queries into one list and keeps the version log. Requests can still come by email, or through a dedicated SharePoint space with your own private login. Many clients prefer our client portal: a request form collects everything the project needs, a notes field holds any specific requirements, urgent jobs can be flagged for priority delivery, and the status and updated timelines of every translation are visible without sending an email. Clients who prefer to stay with email receive a project confirmation as soon as the job is assigned to translators or DTP specialists, with all the project details and the agreed delivery date.
Your translation memory and glossary are applied to every job and belong to you, in portable formats. Our technical translation services follow an ISO 17100 certified process with a second qualified linguist revising every translation; details are on our quality page. Our in-house DTP team delivers files back in their original Word, InDesign, FrameMaker or XML formats, ready to publish. Our teams in Italy, Serbia and Spain work as one, and leverage reporting shows how much of each job comes from reuse.
This is how we work with an Italian manufacturer of industrial equipment that exports most of what it builds. Before, the technical and sales offices had to coordinate language and layout suppliers for each shipment. Now documentation moves from source file to finished, laid-out multilingual documents through one managed process. The details are in the industrial manufacturer case study.
Another client sends us InDesign manuals almost every day. They used to attach every file to an email. Since moving to the portal, which has far more room for uploading and sharing large files, the work moves faster and more smoothly. With requests this frequent, being able to see on the portal when each translation has been delivered makes the whole process far more efficient.
Changing an established way of working can feel daunting, even when the new route is simple. Nothing has to change on day one: you can keep sending requests by email, and if you want to try the portal, you can submit one or more test requests without commissioning a translation, then talk the experience through with us. We also offer training by video call or in person to help your team get started.
Where TUBE fits
For manufacturers with a continuous documentation programme, TUBE changes the starting point of every job. Your glossary and translation memory control machine translation, so approved terms and previously translated content are in place before a linguist starts. Every approved translation goes into a memory you own and can export, and leverage reporting shows how much of each update comes from reuse.
Frequently asked questions
It is the sequence of steps that takes a document from a translation request to a finished file in every target language: preparing source files, applying existing translations and approved terms, translating, revising, answering queries, laying out, reviewing and delivering.
It depends on who runs translation in your company. Software of this kind makes sense when you have a localisation team that can configure and maintain it. When translation is handled by people whose main job is something else, a managed workflow usually removes more internal work than new software.
Not for documents that carry safety or regulatory weight. Automation can speed up file handling, reuse of previous translations and machine translation of recurring content, but warnings, instructions and anything in a CE technical file still need a qualified linguist and a second check.
Use one request point and a standard request, send editable source files, apply your translation memory and glossary to every job, collect source queries into one list, and agree in advance how urgent requests and late source changes are handled.
Agree a clear scope (technical accuracy and terminology, not style), give reviewers a deadline with a default release if no comments arrive, and feed their terminology preferences into the shared glossary so the same correction never has to be made twice.
Yes. What matters most is that your translation memory and glossary belong to you, in portable formats, and are used on every job, whoever does the work.
Stop coordinating translations by email
If your technical office spends more time chasing translations, versions and status than it should, describe how your translation requests work today. We will look at your documents, formats and languages and show you what a managed workflow would change.
How can we help?
Tell us what you need and we’ll get back to you with the solutions.