The economics hinge on one number. Reuse rate
Technical Publications owns the manual portfolio and the translation budget. The economic argument lives here: source content × language count × refresh frequency × per-word rate, with reuse rate sitting in front of every term in that equation.
Duplicate content is paid for three times
A maintenance manual exists in twelve languages, refreshed twice a year, with 30% overlap against the installation manual for the same product family. Every overlapping sentence is paid for three times: written once, translated once, retouched at the next refresh.
Structured content removes the overlap. One sentence, referenced from both manuals, translated once per language, refreshed everywhere it appears. Reuse rate becomes the lever, not the per-word rate.
What an 80% reuse rate looks like on the invoice
A worked example. The numbers are conservative against most multi-product technical-publications teams we see.
Multiply by the per-word translation rate. Multiply by refresh cycles per year. The figure is rarely the bit that decides the business case; the bit that decides is the speed of source-content updates, because the cycle now stops at one component instead of every manual that contains it.
What changes for Technical Publications
| What changes | How |
|---|---|
| A reuse rate that compounds across the portfolio | Component library, every approved fragment available to every document. Where-used reporting at the fragment, so the reuse rate is a measurable number, not a hope. |
| Translation cost that scales with change, not with volume | Per-language translation packages generated in one operation. Only changed fragments retranslate. Translation memory and reuse compound. |
| Multi-format output without parallel pipelines | One-click publishing inside Dx5: Word, HTML, XML, portal pages, API endpoints. Output format chosen at publish time, not designed upstream. |
| SMEs who actually contribute, instead of forwarding Word documents | DxAuthor+, the Word add-in. SMEs stay in the tool they know. The DITA structure is applied behind the scenes. No second tool to defend in the SME group. |
| Governance that lives in the workflow, not in a process document | Built-in approval workflows. Version history at the fragment. Snapshot capability for release freezes. The governance is enforced; it does not depend on someone remembering. |
Where Technical Publications teams use DitaExchange
Industrial manufacturing
Installation, operation, maintenance manuals across product families. Customer: Grundfos.
Aerospace and defense
Technical publications across NATO and EASA standards, multi-variant manuals, ASD-STE100 controlled language. Customers: Lockheed Martin, GKN Fokker.
Medical device
Instructions for use, service manuals, training materials per market. Customers: MagVenture.
Nuclear and energy
Reactor manuals, plant safety cases, decommissioning records. Customer: Canadian Nuclear Safety Commission.
The common thread is reuse, translation cost, and SME participation. The sector determines the regulatory overlay; the economics are the same.
Frequently asked questions
Where does the conversion effort actually land in a publications team?
On decisions, mostly. DxMigrationTool captures metadata, aligns styling, repoints references and splits documents into topics, but which manual family goes first and how it breaks into topics are calls the team makes. The phasing is what keeps the work shippable: new content authored as components from day one, one set converted first, the rest as each document comes up for revision.
Do we need a full controlled-language program before DxChecker is useful?
No. A ruleset can hold one rule or several hundred, and you choose which ruleset runs. Start with what a reviewer currently polices by hand: approved terms, banned phrases, date formats, heading structure, link validity. Each rule is a readable XML file with an assert statement and optional auto-fix instructions, so the set grows as your standard gets written down.
Our manuals have a designed page. What does publishing actually produce?
Word, HTML and XML, plus portal pages and API endpoints, with the format chosen at publish time rather than designed in upstream. Per-language translation packages are generated in one operation. If the value of your deliverable sits in a page composition engine rather than in the content, test that specific output early, because it is the part of the pipeline the format list has to satisfy.
What keeps related manuals from falling out of step once they share components?
Compound document sync keeps related content aligned, where-used reporting names every manual that references a changed fragment, and broken link and orphan detection catches the references that stopped resolving. Version comparison shows the diff between revisions. None of that decides whether a given variant should carry the change, which is why conditional profiling exists as a separate control.
We publish into a customer portal and an in-app help system. How do those get content?
Through the Dx5 API. Its REST endpoints expose components, maps and assemblies to downstream consumers, so a supplier portal or an in-app help system reads the approved component instead of holding its own copy of the text. When the component changes, what the application shows changes with it. Portal pages are also a publishing target inside the platform.
Start where the translation budget is most visible
Most Technical Publications rollouts begin with the document family where translation cost is highest and the overlap with adjacent families is largest. Reuse rate moves first; the rest of the portfolio follows.
