Translation Management System or Managed Workflow? How Documentation Teams Should Decide
Do you need a translation management system, or can a translation partner manage the workflow for you? Buy a TMS if you have staff to run it, continuous software strings or many suppliers to coordinate. If you publish manuals a few times a year, a workflow managed by a partner such as DEMA Solutions keeps you in control with far less internal work.
Who this guide is for
This guide is for the person who has just been handed the question. You may run technical documentation at a manufacturer of machinery, HVAC equipment or industrial components, or sign off documentation spend in operations. Somebody, perhaps IT, a parent company or a colleague who used one in a previous job, has suggested that the company should get a TMS. It sounds like a sensible step, and sometimes it is exactly that.
Your content is mostly documents: operating and maintenance manuals, spare parts catalogues, safety instructions, datasheets, training material and perhaps a set of HMI texts. They are written in InDesign, FrameMaker, Word or an XML authoring environment, and they change when the products change. You probably have no localisation department. Translation is one of several responsibilities on your desk, so the useful question is not which software makes the best impression in a demo. It is which arrangement takes work off your team while keeping terminology, translation memory and quality decisions with your company.
We compare no products here. The aim is to explain what the category does, what owning it involves and how a managed workflow differs, so you can decide on your own facts.
What is a translation management system, and what does it actually do?
A TMS is software that turns translation into a repeatable, tracked process. It receives content, moves it through defined steps, applies the linguistic assets you already have and returns the translation to where the content came from. The abbreviation covers the whole category, from tools for small teams to large group installations, and most products combine six functions in different proportions.
A workflow engine. Each type of job follows a template: preparation, translation, revision, review by the client, final check, delivery. The system assigns each step to a person, sends notifications and tracks deadlines, so that a project follows a defined route instead of a chain of messages.
Central storage for translation memory and termbases. Approved sentence pairs and approved terms sit in a shared repository on a server, so several linguists can draw on the same assets at the same time and every finished job adds to them. The system stores and serves these assets. How useful they are still depends on what goes into them and how carefully they are maintained.
Machine translation integration. The system connects to one or more machine translation engines and applies rules: which content types are sent to machine translation, which engine is used for which language pair, and whether an existing memory match takes priority over machine output.
Vendor and linguist assignment. A register of suppliers and individual linguists holds language pairs, specialisations and rates. Tasks are offered or assigned from it, and some products add cost estimates and purchase orders.
Connectors to content systems. Integrations with web content management, code repositories, product information systems or documentation authoring tools pull new and changed content automatically and push the translations back. For software and websites this is often the main reason a company buys.
Reporting. Volumes, costs, turnaround times and memory leverage by language, supplier, product or department.
An enterprise translation management system adds organisational layers on top: single sign-on, permissions for many departments and subsidiaries, approval chains across countries and budget reports by cost centre. The principle stays the same. The company owns and operates the machinery of translation, and suppliers and linguists connect to it. One point is easy to miss in a demo: the software organises translation, but it does not translate. You still need qualified translators, revisers, someone who looks after terminology, layout specialists for documents and a person who keeps each project on schedule.
What running a TMS in-house really involves
The purchase is the simple part. Whether it pays off depends on the work that follows, month after month.
Licences and seats. Pricing models vary: by user, by volume, by connector or a mix. Deciding who needs access usually reveals more people than expected: requesters, coordinators, subsidiary reviewers and the external linguists working inside your environment.
An internal owner and administrator. Someone must configure workflow templates, roles and notifications, find out why a job is stuck and apply updates. In practice this lands on the documentation manager or on a new role. When that person moves on, the knowledge of how the system was set up often leaves too, unless it was written down.
Vendor onboarding. Every supplier and freelance linguist has to be registered, given access, shown your configuration and kept up to date on rates and language pairs. With a TMS, your company becomes the coordinator of its own supply chain. The software provides the means; your people still do the coordinating.
Configuring machine translation. Choosing engines per language pair, deciding which content may go to machine translation at all, linking glossaries where the engine allows it, and making sure qualified linguists post-edit what matters. A careless setup produces fluent text with the wrong terms, which is harder to catch than an obvious error.
Maintaining connectors. Content systems are upgraded and interfaces change. A connector that silently stops picking up changed content is worse than none, because nobody notices until a language version is out of date.
Training reviewers. The engineer at the German subsidiary who checks two manuals a year has to learn the review interface, and will probably need a reminder next time.
Keeping memories and termbases clean. Duplicates, outdated terms and conflicting translations of the same sentence accumulate. Cleaning them is linguistic work, not IT work, and if nobody owns it the shared memory spreads inconsistency instead of preventing it.
For documents there is one more point. Layout after translation, text expansion in tables and rebuilt cross-references in InDesign or FrameMaker all happen outside the workflow engine. None of this is a reason not to buy. It is the job description that comes with the purchase.
When buying a TMS is the right decision
For some companies a TMS is clearly the right tool, and a good translation partner should say so. The pattern is usually easy to recognise.
You have a localisation team, or you are ready to create one. If there are people whose actual job is running translation, they will configure the system properly, keep it maintained and get real value from its reporting. A TMS without an owner tends to become an expensive inbox; with an owner, it becomes the backbone of the function.
Your content is a continuous stream of software strings. Product interfaces, apps and web content that change with every sprint need automated round trips: developers commit new strings, the system picks them up, linguists translate them in context and the translations flow back into the build. Here developer integrations matter more than anything else, and trying to run this by sending files back and forth adds friction to every release. The steps involved are described in our guide to the software localization process, and for this kind of content owning a TMS is often the sensible choice.
You deliberately work with many suppliers and want to coordinate them yourselves. Some groups keep separate suppliers by region, language or content type and want one place to assign work, share assets and compare cost and quality. A TMS gives that coordination a home. How companies organise that kind of supplier landscape, and which governance rules it needs, is the subject of our article on managing translation across multiple vendors and markets.
A team of in-house translators who need a shared environment, or a daily flood of short content items from a web content system, point the same way. If two or more of these descriptions fit, a TMS is probably a good investment, and a translation partner can work inside it as one of your suppliers.
When a managed translation workflow fits better
A managed workflow means that a translation partner operates the process and the technology on its side, while your company keeps ownership of the content and the linguistic assets. You send files and receive finished documents. The partner’s project manager, linguists, terminology specialists and layout team run everything in between.
This model fits documentation teams without localisation staff. When the people who request translations also write the manuals, every hour spent administering software is taken from the source documents, and one point of contact serves them better than a system to look after.
It fits document-based content. Manuals in InDesign or FrameMaker, Word documents built on a corporate template and the occasional PDF from an old product range bring their hardest problems at the file and layout stage: preparing the files, protecting what must not be translated, absorbing text expansion and producing print-ready output in every language. A partner that does multilingual desktop publishing as part of the same job solves those problems where they arise, rather than leaving them for after the workflow has formally finished.
It fits a rhythm of a few releases a year. Much of the automation value of a TMS lies in frequent small updates. When your content changes in a handful of larger batches per year, the fixed effort of owning the system stays the same while the benefit of automation shrinks. The rest of the workflow, from the request to the delivered file, is set out step by step in our guide to translation workflow for manufacturers.
A managed workflow is not the absence of technology: memory, termbases, machine translation and project tracking are all still used. What changes is who operates them and keeps them in order. Whether translation should be handled inside the company at all is a separate decision, and our comparison of translation outsourcing and in-house translation deals with it.
Who owns the translation memory and termbase in each model
In both models the answer should be the same: your company. The model changes where the assets sit from day to day, not who they belong to. It is worth checking this explicitly, because ownership is decided by contracts and file formats, not by good intentions.
With your own TMS, the memory and termbase live in your installation or subscription, and you control who sees them. The risk moves elsewhere: if you change software, you need a complete export with metadata preserved as far as the formats allow. Memories that suppliers built before your TMS existed also have to be collected and imported, or they stay outside your control.
With a managed workflow, the assets are maintained on the partner’s side while the work runs, and the contract should state plainly that they are yours and delivered on request. In either case, insist on the exchange standards, TMX for translation memory and TBX for terminology, and ask for a test export early, while nothing depends on it.
Many manufacturers also have years of approved translations that exist only as finished documents. Those can be recovered by pairing source and target files sentence by sentence, the work described on our page about translation memory and alignment. A memory locked inside a supplier’s database and one locked inside a software subscription are the same kind of dependency. Portability is what removes it.
Terminology and machine translation control in each model
Terminology is where the two models feel most different in practice. With a TMS, your team decides how the termbase is structured, who may add or change terms, how forbidden terms are flagged and whether the termbase is passed to the machine translation engine. The control is complete, and so is the responsibility. If nobody maintains the termbase, the system enforces outdated terms just as reliably as correct ones.
With a managed workflow, terminology specialists on the partner’s side extract candidate terms from your documents, propose them to your engineers for approval, and keep the approved glossary applied on every job and in every language. Our page on terminology management describes how that work is organised. The decision about which term is correct stays with your company, because only your engineers know whether a part is a “pressure relief valve” or a “safety valve” in your product range.
Machine translation follows the same logic. In your own TMS you choose the engines, write the rules and decide who post-edits. In a managed workflow the partner configures machine translation so that your glossary and memory steer it, and qualified linguists post-edit and revise the output. Where machine translation is good enough for technical documentation, and where it is not, is discussed in our article on machine translation post-editing. In both models, the question to ask is the same: what stops the engine from using a term your engineers have rejected?
The hybrid option: keep your systems, hand over the workflow
The choice is not always one or the other. Two hybrid arrangements are common among manufacturers, and either may describe your situation better than a pure model.
In the first, you keep a content system and let a partner run the translation workflow. Your XML component content management or web content system stays the master for source versions and publishing. Changed content is exported in the system’s exchange format, translated and revised by the partner with your memory and glossary, and returned in the same format for import. Nobody inside the company has to become a translation administrator. It also works the other way round: a company with a TMS for its software strings can still hand manuals and layout-heavy documents to a partner, because that is where the system adds least.
In the second, a company with several suppliers needs one set of linguistic assets before it needs new software. Subsidiaries and acquired businesses often bring their own suppliers, each holding its own memory, and buying a TMS only to bring those memories together can be more machinery than the problem requires. A multi-vendor translation memory, maintained for you and shared with every supplier, consolidates the assets now and leaves the software question for later, when you have better information.
Questions to ask before you buy or outsource
Whichever way you lean, six questions tend to separate a good decision from an expensive one. Answer them internally first, then put the relevant ones to software vendors and translation partners.
First, who on our side will own the system, and how much of their week can they realistically give it? If the honest answer is “nobody in particular” or “a few hours when there is time”, that is a strong signal in itself.
Second, what share of our content is continuous strings and what share is documents with layout? A TMS earns most where strings flow constantly through developer pipelines; a managed workflow earns most where files have to be prepared, translated and laid out again.
Third, how many suppliers do we coordinate today, and do we want to keep coordinating them? A TMS makes that coordination more organised. It does not make it disappear.
Fourth, where do our translation memory and termbase live today, and can we obtain them in TMX and TBX within a week? If the answer is unclear, settle it before any other decision, because both models depend on it.
Fifth, how will terminology be approved, and how will machine translation be prevented from overriding it? Ask a software vendor to show the configuration, and ask a partner to explain the process and who signs off each term.
Sixth, what will the total internal effort look like after the first year, once reviewers, connectors, layout and memory maintenance are included? Compare that, not the licence fee or the price per word, because the effort that falls on your own people rarely appears in either quote.
How DEMA Solutions runs managed translation workflows
We run translation for documentation teams that would rather not operate the machinery themselves. On our side, you have one commercial contact, your sales manager, who works closely with a dedicated project manager. That project manager learns your products, file types and reviewers, so a new request does not need a new briefing.
You can send requests in whichever way suits your team. Email remains perfectly workable, and once a job is assigned to translators or DTP specialists you receive a project confirmation with the details and the agreed delivery date. For larger packages we can set up a dedicated SharePoint space with your own private login. Many clients use our client portal, which has a request form for all project information, a notes field for specific requirements, a flag for urgent jobs that need priority delivery, and a view of the status and updated timeline of every project.
The translation itself follows our ISO 17100 certified process: a qualified linguist translates, and a second qualified linguist revises the text against the source before delivery. The details are on our quality page. Our in-house DTP team returns InDesign, FrameMaker, Word and XML files in their original format, laid out and ready to publish. Your translation memory and termbase are delivered in TMX and TBX whenever you ask. Our teams in Italy, Serbia and Spain work on your projects as one team.
If you are not ready to change how you work, you do not have to. You can submit test requests without commissioning any translation and discuss the experience with us afterwards, and we offer training for your team by video call or in person.
Where TUBE fits
If your team was looking at a TMS mainly to get control without hiring a localization manager, TUBE is worth comparing. It is not a product you buy and configure: it is the solution DEMA uses to run your translation work on your behalf. Machine output is steered by your own glossary and memory rather than by a generic engine, each translation you approve is stored in a memory that remains your property and can be exported at any time, and a leverage report on every update shows the share that came from reuse. That report is often the very visibility a TMS purchase was meant to deliver.
Frequently asked questions
Do we need a translation management system, or can a translation partner manage the workflow for us?
It depends on who will run translation and what you translate. A TMS makes sense with a localisation team, continuous software strings or many suppliers you coordinate yourself. For documentation teams publishing manuals and documents a few times a year, a partner that manages the workflow usually gives the same control over memory and terminology with less internal effort.
A CAT tool is the environment in which a linguist translates, with translation memory and termbase lookups as they work. A TMS organises projects, people and assets across many jobs: workflow steps, assignments, connectors and reporting. Many products combine both.
It can be, when someone inside the company has the time and mandate to own it and the content changes often enough for automation to pay off. When translation is a side task for the documentation team and most content is documents with layout, the effort of running the system often outweighs its benefits.
Your company should own it in both. With your own TMS, make sure you can export everything when you change software. With a managed workflow, make sure the contract states that the memory and termbase are yours and that they are delivered in TMX and TBX on request.
Yes, provided your memory and termbase are kept in portable formats. Assets delivered in TMX and TBX can be imported into most software, so a later decision to bring translation management in-house does not mean starting again.
Usually, for suitable content. The difference lies in control: machine translation should be steered by your approved glossary and memory, and its output post-edited and revised by qualified linguists, especially for safety instructions and regulated documentation.
No. TUBE is DEMA Solutions' managed translation solution, built around your glossary and translation memory. You do not license or operate it; we run the workflow for you, and the memory built along the way belongs to you.
Tell us how your content is produced and released
The right model depends on your content, not on a feature list. Describe your content types, languages and release rhythm, and we will tell you honestly which model fits, including when the better answer for your company is a TMS of your own.
How can we help?
Tell us what you need and we’ll get back to you with the solutions.