If your company ships a family of models off one platform and republishes the manual for each variant, this article is about a line item you have probably stopped questioning. If you publish one manual per product and rarely revise it, there is less here for you.
When the documentation budget gets squeezed, most teams look at the translation stage. They renegotiate the per-word rate. They put the work out to bid. They pilot machine translation.
The number on that invoice was mostly settled earlier. It was settled while the source manual was being written, and it compounds with every derivative that follows.
There is a fast way to check this for yourself. Pull the analysis log from your last localization quote, the one that breaks the file into 100 percent matches, fuzzy bands, and new words. If your product is a derivative and the new-word count is not small, the problem is upstream of the vendor you are negotiating with.
A 30 percent change spreads across the whole book
Platform strategy on the engineering side arrives at the documentation team as workload.
Even when a new model differs from the previous one by less than 30 percent, most teams handle the manual the same way. They copy the previous file and review it end to end.
They do that because the 30 percent is scattered rather than concentrated. Occasionally a whole section gets added or deleted. Far more often a derivative brings a performance change to an existing feature, one added option, a different menu path, a revised screen. Those edits land a few per page across the entire book. No chapter can be safely skipped, so the technical writer reads all of it.
Up to this point, standard sentence management changes nothing. The difference starts one step later.
The same 30 percent produces different results depending on who did the work
Reading through, the writer reaches a spot that changed. At that spot, writing a fresh sentence is faster than surgically editing the existing one. So that is usually what happens.
Here is what the writer does not know. The feature that looked new already appears in a sibling model the writer never worked on. Someone already described it, and that description was already translated into every target language. Following the style guide correctly, the writer produces a different sentence for the same thing. The content was already paid for. The wording changed, so it gets billed again.
There is a second problem underneath the first.
Any competent technical writer can describe the same function in several defensible ways.
“You can cancel phone pairing by pressing any button.”
“Press any button to cancel phone pairing.”
“Cancel phone pairing by pressing any button.”
“Phone pairing can be canceled by pressing any button.”
All four are accurate. All four survive a style guide review. Any user who reads any of them will cancel phone pairing successfully.
The problem shows up downstream. To a reader these are one sentence. To a translation memory they are four. The same drift happens even when one writer covers several models, because wording shifts from book to book over a year.
The individual sentence is fine. The pattern of divergence is the problem.
A sentence written against the glossary and the style guide has nothing wrong with it. Pick any of the four above and the user is served. The case for standard sentence management does not rest on the quality of any single sentence. It rests on what accumulates once sentences are allowed to drift.
The books in a product family stop agreeing with each other. When the Model A manual and the Model B manual describe the same function differently, that difference carries forward depending on which book the next derivative is built from. Over several product generations, one family ends up with several ways of saying the same thing, and the documentation set loses its through line. Service literature, training material, and support scripts drift along with it, because they are usually built from whichever manual was handy.
Then multiply by your language count. Say you publish in eight languages, which is modest for a manufacturer selling into the EU and Latin America. One sentence that drifted in the source drifts in eight target files. A difference that was easy to wave through in English review comes back as a question from a regional distributor, and someone has to spend an afternoon establishing that both versions were correct all along.
And it lands on the invoice. A sentence that was already translated, rephrased, falls out of the 100 percent band and into fuzzy. Rephrase it enough and it is billed as new. As the language count grows and derivatives stack up, the leakage compounds. It stays invisible because nothing looks broken. No user ever complains about it.
So the team issues a reuse policy
After a few cycles of watching derivative manuals cost about what an original costs, someone acts. The team confirms that similar sentences for the same function are scattered across books and models, and issues a directive to reuse existing wording wherever possible.
It works, partially. Writers with a few years on the product remember what they wrote for the last model and reproduce it. Within a year or two, the same complaints surface.
- Several similar sentences exist for the same function across several models. The writer finds them, but no version is designated as the one to follow, so the choice gets made again every time.
- Two writers describe the same thing differently. As in the pairing example, neither is wrong. They are simply different.
- When a writer leaves the team, output quality visibly shifts.
- Nobody remembers why a phrase or term was settled a certain way three years ago, so the same argument gets relitigated.
The symptoms look unrelated. The root is one thing. The policy says reuse. It never says what to reuse.
Reusable content comes from designation
When nothing is designated, the decision falls to the individual every time. The writer searches memory for a sentence, and writes a new one when memory comes up empty.
Memory is stored in people. It leaves when they leave, and a new hire never had it. Ten writers with ten sets of recollections will produce ten versions of the same sentence.
Standard sentence management moves that memory out of people and into a list that writers consult while drafting. It replaces recall with lookup.
Documentation becomes an asset on the day its sentences are designated.
Manuals are born and retired with the products they document. Designated sentences outlive the product generation.
What to designate, and what to leave alone
The most common failure starts with ambition. Try to make every string an asset and the list bloats. Once finding a sentence costs more than rewriting it, the list is abandoned, because lookup has stopped being faster than recall.
What belongs on the list depends on your documentation, so build the criteria around your own books. As a general rule, designate only sentences with a real chance of appearing in a future model. Sentences repeated across several manuals qualify. Sentences that go out in every language qualify. Copy written once for one document does not. Writing down what you will not register matters as much as writing down what you will.
The unit of management is the sentence. Headings, lead-ins, individual procedure steps, individual list items, and safety messages each need to stand as their own entry. Group them into paragraphs and you lose the ability to recombine. Break them into terms and you lose the context that makes them reusable.
For most manufacturers the highest-value place to begin is the safety content. Warning and caution messages built to ANSI Z535.6 are already formulaic by design, they repeat across an entire product family, and they carry the most risk if two books word the same hazard differently. They are the easiest sentences to standardize and the most expensive ones to leave alone.
How a team with a standard sentence list builds a derivative manual
They still copy the previous file. They still read the whole book to catch scattered changes. What differs is the moment the writer arrives at something that needs to change.
The writer does not draft. The writer searches the list first. If the sentence is there, it gets pulled in as written, and personal preference has no room to operate.
If the listed sentence is close but not usable as is, the writer edits only the part that has to change and holds the rest of the wording steady.
If nothing on the list fits, the writer drafts a new sentence, and that sentence gets registered for the next model.
When the file reaches translation, the memory sorts it out. Untouched sentences pass at 100 percent. Partially edited sentences price at a fuzzy band. Only genuinely new sentences carry the full rate.
None of this depends on who did the work.
A writer with ten years on the product and a writer in their first month pull the same sentence from the same list. The same is true of two different agencies. Output stops tracking the tenure and the prose instincts of whoever was assigned.
For a documentation manager, that means hiring and attrition stop being quality events. What used to walk out the door with a senior writer now stays on the list. Bringing in a contractor during a heavy release quarter stops being a risk you have to price in.
It is still the same 30 percent change. Far less of that 30 percent now prices as new.
The four complaints, revisited
The four symptoms above look like separate problems and share one cause, so they resolve together once designation is in place.
Nobody has to decide which version to follow, because the list already decided. Wording stops varying by author. Sentences on the list were translated years ago and already sit in the translation memory, so pulling one in returns a 100 percent match and no charge.
The larger your language count, the larger the swing in both directions.
Hansem Global has run this model for more than twenty years on a high-volume consumer electronics program, where over a hundred source manuals a year become several thousand language variants. On a book of roughly 200 pages, about 30,000 words by word count, close to 90 percent of the volume falls into the 100 percent or fuzzy bands. Genuinely new sentences run under 10 percent. That is the combined result of accumulated memory and disciplined sentence management, and it holds year over year.
That is the far end of the curve, and most manufacturers will never publish at that volume. The mechanism is identical at eight languages and four new models a year. What changes is how quickly the leverage accumulates, and even a two-year-old list will show up on your next analysis log.
Because designation holds the source steady, every localized version inherits that stability. The amplification described earlier runs in the useful direction.
And when someone asks why a phrase reads the way it does, a change history on the entry answers it in seconds instead of reopening the debate.
Every change to the list gets a category
Once the list exists, every change to it gets classified at the moment of entry. This is the step that makes the largest practical difference.
| Category | What it means | How translation handles it |
|---|---|---|
| New | A sentence written for the first time because a feature or component is genuinely new. | Full new-word rate, once. |
| Replacement | The old sentence is retired. Every book from now on uses the new one. | Full new-word rate, once, and it propagates everywhere. |
| Variant | A conditional sentence that lives alongside the base sentence. Record the condition that triggers it. | Existing translation stays. Only the new string is added. |
This matters because the downstream handling follows automatically from the category. Log everything as “revised” and someone in the localization workflow has to make the call by hand on every file. Those calls come out differently every time.
For the same reason, settle your retranslation triggers in advance. When a source change lands and the need for retranslation gets judged by feel, teams either over-order to be safe or miss something that mattered. Put the rule in a table and the judgment becomes a lookup.
Where to start
If this reads like a case for buying a component content management system, it is not meant to. A CCMS is a reasonable purchase later, and it will not create the discipline for you. Teams that install one without a designation rule end up with the same scattered wording in a more expensive container.
The starting kit is a spreadsheet, a shared drive, and a rule the team actually follows. Hansem Global has operated reusable content this way for more than twenty years in programs where dozens of derivative models ship annually against constant spec changes and regional variation.
Somebody has to own the list, and this is where teams usually stall, because ownership sounds like a headcount request. It is not. Give one existing team member edit rights and final review authority. Writers propose additions on a set form and the owner approves them in.
If your source content arrives from contract writers or from engineering, the payoff is larger, not smaller. Issue the list to them up front and you stop divergence at the door instead of cleaning it up in review.
The first concrete task is small. Take one current manual, break it into sentences, and mark which ones also appear in other books. That single pass tells you two things: what share of your content is genuinely reusable, and how many near-duplicate sentences you are already paying to translate twice.
What this buys you
The cost of a derivative manual is not decided at the translation stage. It is decided as the source is written.
Designate the sentences. Settle who can change them and through what process. Record why each decision was made.
Three things follow. Output stops varying with the tenure and writing instincts of whoever is assigned. The books in a product family, and their localized versions, stop contradicting each other. And the localization spend comes down in a way you can see on the next analysis log.
No system does this work for you. The discipline comes first. The tooling comes after.