Content Reuse Starts with a Sentence Library

A manufacturer can build a working content reuse system without buying a component content management system. This white paper documents the standard sentence library methodology Hansem Global has run for more than 20 years inside one of the most demanding documentation environments in the world, the manual program of a global mobile device manufacturer, and reduces it to a form a mid-size manufacturer documentation team can adopt with a spreadsheet and a set of rules.

Table of Contents

• Executive Summary
• 1. Why documentation cost scales up with product count
• 2. What a CCMS solves, and what it costs
• 3. A discipline-based content reuse system
  • 3.1 Sentence library design
  • 3.2 Governance: who is allowed to change the library
  • 3.3 Reuse mechanics: where the asset becomes a cost reduction
  • 3.4 Supporting infrastructure: the file discipline underneath
  • 3.5 (Optional) Putting an app on top of the library
• 4. A four-phase adoption roadmap
  • Phase 1. Sentence inventory (roughly 1 to 2 months)
  • Phase 2. Library construction and standard designation (roughly 2 to 3 months)
  • Phase 3. Governance goes live (roughly 1 month, then ongoing)
  • Phase 4. Translation integration and measurement (roughly 2 to 3 months)
• 5. When to move to a CCMS
• 6. Closing
• Frequently Asked Questions

Executive Summary

Documentation cost that scales with the number of derivative models and target languages is an old complaint in manufacturing. The textbook answer is a CCMS (component content management system). A CCMS is powerful, and between licensing, implementation, content migration, and the productivity cost of retraining an entire writing team, it is also a purchase most mid-size manufacturers cannot justify.

Hansem Global has developed technical documentation since 1990. Across that time one finding has held. Most of what a CCMS delivers comes from operating discipline rather than from the software itself. The proof is a mobile device manual program with dozens of derivative models a year, continuous OS updates, and region-specific variants, where a spreadsheet-based sentence library and a written governance procedure have carried the content reuse system for more than 20 years.

This paper extracts the transferable parts of that system and organizes them along four axes.

• Sentence library design. What gets captured as an asset, at what unit, in what structure.
• Governance. Who is allowed to change the library, and through what procedure.
• Reuse mechanics. The operating rules that turn a stored asset into an actual cost reduction.
• Supporting infrastructure. Versioning, naming, and file discipline that hold the library up.

It closes with a four-phase adoption roadmap and the signals that indicate when moving to a CCMS has become the right call. The goal here is to secure the content discipline an organization needs before it buys a CCMS. A CCMS bought without that discipline fails. An organization that has the discipline captures most of the benefit of reuse without one.

One caveat applies. The value of this methodology scales with the number of derivative models and the number of target languages. An organization that ships few derivative products and publishes documentation in a single language will find little here.

1. Why documentation cost scales up with product count

The platform-and-derivatives product strategy that drives manufacturing transfers directly onto the documentation team as workload. Documentation here means the user guides and service manuals that ship with the product, together with the technical documentation behind them, and in any organization that repeats manual development year after year, the burden grows with product count. Even when the functional delta between a new model and the previous one is under 30% of the manual, most organizations still copy the previous model file whole and review it end to end. The reason is that the 30% is not concentrated in one section. A feature or an entire section does get added or removed outright now and then. Far more often, a derivative model brings performance improvements, added options, changed navigation paths, and revised UI screens. Those edits scatter across pages, so no chapter can safely be skipped. The writer ends up reading everything.

This is a structural problem. As long as a human eye has to hunt for what changed, the cost of review, revision, translation, and QA scales with the total size of the document regardless of how much actually changed. A 30% change billed at 100% of the document is the real shape of derivative documentation cost. That cost splits into two layers. One layer is the review burden of reading the full document again. The other is the translation and multilingual rollout cost that follows from how the 30% gets rewritten. This paper addresses the second layer.

The cost compounds as languages are added. Fix one sentence and every language version containing that sentence has to be found and fixed. If the only person who knows where that sentence appears is the writer who wrote it, a missed update is a matter of time. When the miss happens in a safety statement or a regulatory statement, it stops being a cost problem and becomes a liability problem.

Writer’s due diligence does not solve this. When a writer reviewing the full document reaches a changed feature, the writer rewrites the sentence at that point, because composing fresh is faster than salvaging part of an old one. The problem is what the writer cannot know: the feature judged to be completely new already exists in another model that a colleague handled. A sentence composed carefully to the style guide turns out to be a reworded version of content that was already translated.

The symptoms show up the same way in most documentation teams.

• Similar sentences describing the same function exist across documents and across models. Any one of them could have been designated as the standard, and because none was, the writer has to decide again every time.
• The person who knew why a term or a phrase was settled on three years ago has left the company, and the same argument gets relitigated.
• With no designated standard sentence, every writer phrases the same content slightly differently. Even with a translation memory in place, those sentences do not match anything in the TM, so they are billed as new segments and the translation cost lands again.
• A regulatory statement changes and nobody can produce an accurate list of the documents it affects.
• Documentation quality visibly wobbles whenever the writer changes.

The common cause is that content exists only as documents and is never managed as sentence-level assets. A document is born and retired with a product. A designated standard sentence outlives product generations. The point worth pausing on is that the asset comes from the designation rather than from the quality of the sentence. A beautifully written sentence that was never designated as the standard is just one more candidate the next writer has to evaluate. An ordinary sentence becomes a reusable asset the moment it is designated. What most teams lack is the container and the rules to hold that designation.

2. What a CCMS solves, and what it costs

A CCMS is the software answer to that problem. It stores content as topics or components, assembles multiple documents from a single source, and pushes a change in a reused component out to every document that references it. Add version control, workflow approval, and translation management system integration, and it is close to the ideal environment for a documentation team.

The obstacle is total cost of ownership. Licensing is only the first line item.

• Implementation and customization. Redesigning the existing documentation structure into the CCMS information model, usually a structured authoring standard such as DITA.
• Content migration. Decomposing the entire accumulated document library into components and moving it. This almost always requires outside services.
• Organizational learning. The productivity dip while every writer adapts to structured authoring and a new toolchain.
• Maintenance. A system administrator on payroll or a vendor maintenance contract.

There is a deeper issue underneath the budget. A CCMS delivers value only inside an organization that already has the discipline to break content into reusable units, designate standards, and control change. Deploy one into an organization without that discipline and the disorder simply gets ported into the system. Duplicate components accumulate, nobody can still say which component is the standard, and the same confusion is now reproduced on top of an expensive platform.

What determines whether a CCMS implementation succeeds is not the software. It is the content discipline of the organization. And that discipline can be built without a CCMS.

Hansem Global’s experience is the evidence for that claim. In a global mobile device manual environment where dozens of derivative models, continuous OS updates, and region-specific configurations all collide, the writing organization has run a content reuse system for more than 20 years on a spreadsheet-based standard sentence library and a documented registration procedure. The rest of this paper describes what a manufacturer can take from that system.

3. A discipline-based content reuse system

The system described here assumes no special software. A spreadsheet, a shared server, and a set of rules the team actually agrees to follow are enough. It applies to any organization that repeats the same content across documents, whether the work is manual production or broader technical documentation development. It rests on four axes: sentence library design, governance, reuse mechanics, and the file management infrastructure underneath them.

Before starting, it is worth stating what this system does not reduce. A team running a standard sentence library still copies the previous model file, and still reviews the full document to find the scattered changes. The full-review burden identified in Section 1 does not go away. Reducing that burden belongs to change tracking and delta management. What changes is the moment the writer reaches a point that needs revision. Whether the writer composes a new sentence there or calls up a designated one is what decides the translation and multilingual rollout cost that follows.

3.1 Sentence library design

It helps to be clear about what the library replaces. In an organization with no designated standard, what sustains reuse is the individual memory of each writer. Memory accumulates in a person, so it leaves when the person does, and a newly hired writer starts with none. Ten writers with ten different memories produce sentences that fork ten ways. A sentence library moves that memory out into an organizational asset, and turns work that ran on remember-and-reproduce into work that runs on search-and-retrieve. The six principles below all exist to make that shift hold.

Principle 1. Do not register everything

The most common failure in library construction starts with ambition. An attempt to turn every string into an asset bloats the library, and a bloated library gets abandoned the moment the cost of finding a sentence exceeds the cost of writing it again.

Registration is limited to sentences that get reused or translated. A sentence that recurs across multiple documents or multiple models, or that goes out in multiple languages, is an asset. A phrase used once in one document, or a trivial variation in a navigation path, is not registered. Writing down the criteria for what does not get registered matters as much as writing down the criteria for what does. What deserves designation as a standard varies with the character of each company’s documentation. Treat the criteria above as a common starting point and adjust them to the structure of your own document set.

Principle 2. Mirror the document structure in the library structure

A library where sentences cannot be found does not exist. In a spreadsheet environment with no real search layer, predictability of location substitutes for search. Map the sheets in the library one to one against the chapters in the actual manual, and a writer reaches any sentence on a single rule: sentences from the Getting Started chapter live on the Getting Started sheet. The sheet structure is doing the job a CCMS topic tree would do.

Principle 3. The unit of management is the sentence

One row, one sentence. Headings, lead-in text, each step in a procedure, each item in a list, each note and caution statement lives as its own row. Group content into paragraphs or sections and reuse flexibility disappears. Break it into words and context disappears. The sentence is the smallest unit that keeps meaning intact, and it matches the segment unit used by translation memory, which makes later expansion straightforward.

Principle 4. Keep source and translation on the same row

Register the source sentence and the reference translation side by side in the same row. A library built this way is a translation memory in embryonic form. When translation volume grows to the point that a CAT tool (computer-assisted translation software that lets a linguist work against a TM and a glossary) makes sense, the bilingual asset migrates into a TM with no reprocessing. The point is to start on a spreadsheet without starting down a dead end.

Principle 5. Classify every change as one of three types

Every change to the library gets one of three verdicts at the moment it is registered.

• New. A sentence written for the first time because of a new feature or a new component.
• Replacement. The old sentence is retired and a new one takes its place. Every document from that point forward uses only the new sentence.
• Variant. A conditional sentence that runs in parallel with the base sentence. The condition that triggers the variant, such as a specific hardware configuration or a specific sales region, is always recorded with it.

This classification matters because it decides downstream handling automatically. A replacement triggers retranslation in every language. A variant leaves the existing translations intact and adds a new one. Collapse all of it into the single word “revision” and a human has to make that call at translation time, every time, and the call comes out differently every time.

Principle 6. The history is worth more than the sentence

Give every sentence in the library a history field, and record three things whenever it changes.

• Date and effective point (which product, from which version)
• Substance of the change
• Reason and requester (who asked, and why)

In a library that has run for several years, the most valuable content is the history rather than the sentences. The question “why is this phrased this way?” comes back every time a writer changes and every time a new stakeholder appears. Without a history, the team repeats the same review and the same argument from scratch. With one, the reasoning behind a decision made four years ago is available on the spot.

One practical rule belongs here. Ban vague entries in the reason field such as “engineering request” or “quality team request.” The condition and the specific problem that drove the change have to survive in writing, because that is what allows the sentence to be reverted once the condition goes away.

3.2 Governance: who is allowed to change the library

The approval gate

A reuse system always collapses the same way first. Someone under deadline pressure quietly edits the library. Even a well-intentioned edit, if it lands without review, costs the library its status as the single trusted source and demotes it to a reference document. A reference document stops being updated, and a library that stops being updated is abandoned shortly after.

So the rule is simple. Writers do not edit the library. A writer proposes a new or changed sentence on a fixed form, and it reaches the library only after the approver reviews it. The proposal form carries the change classification from 3.1 (new, replacement, variant), the applicable product, and the reason. A color convention on the document itself, such as highlighting changed sentences in a designated color and using comments to record classification and reason, is sufficient without any additional tooling.

The librarian: designate the role instead of hiring for it

Designate an owner for the library, a librarian. This does not mean hiring someone. It means explicitly assigning edit rights and final review responsibility to one existing team member. The librarian does the following.

• Confirms that a proposed sentence does not duplicate an existing standard.
• Checks that classification and history entries follow the rules.
• Announces confirmed changes to the whole team.

Special handling for safety and regulatory content

Warning and caution statements, and certification-related content, get managed at a different tier than ordinary sentences, because an error there converts directly into legal exposure. For US-market products this covers ANSI Z535.6 safety messaging in product manuals, OSHA-driven warnings, FCC and UL statements, and any labeling content governed by FDA or CPSC requirements. Give edit rights on this tier to one designated person, route every change through quality or legal review, and store it in a separate, deliberately hard-to-touch folder rather than alongside general content.

The batch cycle: collect, then decide

Processing change proposals one at a time as they arrive turns review into a formality and fragments the history. Set a regular cycle, weekly or biweekly, collect the proposals from that window, and review, confirm, and announce them together. Whatever the interval, what matters is that the rhythm of collection cutoff, review, and confirmation announcement is fixed. Writers know when a proposal has to be in and when it will be confirmed. Library users trust that the library is current as of the last announcement.

Controlling manuscripts at the point of entry

A team that receives manuscripts from outside vendors or from engineering departments gets even more from the library. Issue the standard sentence list before work begins and name it as the acceptance baseline for deliverables, and inconsistent phrasing gets stopped at the door. Unifying phrasing after delivery usually means re-reviewing the full source. Setting the baseline before delivery means handing over one list. The larger the share of outsourced writing, the stronger the case for writing this issuance step into the governance document.

3.3 Reuse mechanics: where the asset becomes a cost reduction

Link shared assets, do not copy them

Content that goes into every product without exception, such as certification marks, the common safety section, standard corporate statements, and shared icons, becomes a liability the moment it is copied and pasted. The original changes and the copies do not. Keep a single master file for this content and reference it by link from each document. Professional authoring tools such as InDesign and FrameMaker, along with most word processors, support linked file insertion, so there is nothing to buy. Update the master and every referencing document picks it up.

Expose only the current version

Using an outdated file by mistake is not a problem training solves. People use the file in front of them. The fix is to keep only the current version on the master path, and to move the previous version into a completed folder the moment work starts on a new one. One rule: anything visible in the master folder is safe to use. For that rule to hold, archiving has to happen immediately.

Why a translation memory alone does not reduce translation costs

Teams that run a TM often assume they have already stopped paying twice for the same sentence. For 100% matches, that is correct. The leak happens one step earlier.

With no designated standard sentence, each writer phrases the same content a little differently. “Press and hold the power button for 3 seconds” and “Hold down the power button for at least 3 seconds” mean the same thing to a person and are two different segments to a TM. The match rate drops, a fuzzy or new-segment rate is applied, and a linguist translates content that was already translated.

TM match tier	Typical rate applied	What creates this tier
100% match	Little to no charge	The writer reused an approved standard sentence verbatim
Fuzzy match (75 to 99%)	Discounted rate	The writer rephrased an existing sentence, often without knowing one existed
No match (new segment)	Full rate	The writer composed a fresh sentence for content that was already written and translated before

This is where the savings from standard sentence management actually come from. They do not come from refusing to pay again for a 100% match, because a TM already handles that. They come from preventing the unnecessary new segment from being created in the first place. Every near-duplicate sentence a writer invents is an invoice line. Designating standard sentences is a cost control measure before it is a style measure.

A retranslation decision table

The largest source of waste in a multilingual document set is retranslation nobody needed. When a writer judges case by case whether a source change requires retranslation, the cautious ones over-order and the confident ones create gaps. Fixing the criteria in a table in advance turns that judgment into a rule.

Verdict	Type of source change	Action
Retranslate	Feature or control name changed	Extract the affected strings only and send those
Retranslate	Section added or removed	Extract the affected strings only and send those
Retranslate	Sentence content revised	Extract the affected strings only and send those
No retranslation	Image or screenshot swapped, text unchanged	No translation request
No retranslation	Layout or pagination change, text unchanged	No translation request
Check first	Source typo or style correction	Compare against the target text, then decide

When retranslation is required, send only the changed sentences as a delta report rather than the whole document. This is where the insistence on sentence-level management in 3.1 pays off. Only content managed at the sentence level can be extracted at the sentence level.

Output that holds steady through staff turnover

The savings from standard sentence management show up first in the translation budget. What matters more to a manager is that variation in output shrinks. In a team where the library has taken hold, a ten-year veteran and a writer assigned to the project for the first time consult the same list and pull the same sentence. Vendor A and vendor B deliver the same result. The level of the output stops depending on the experience and prose skill of whoever happens to be assigned.

This also separates documentation quality from hiring and turnover. What used to walk out the door with one experienced writer now stays in the list. Assigning a new hire, or adding people when volume spikes, becomes a decision the team can make without pricing in a separate quality risk.

Quantifying reuse: how a documentation team proves savings

The language industry prices against match rate as standard practice. A 100% match costs little or nothing, a fuzzy match (typically 75 to 99%) draws a discounted rate, and only a new segment draws the full rate. A team running a sentence library can calculate that match rate on every derivative model project, which means it can report in dollars how much the library saved on that project.

The figures observed in the multilingual manual programs Hansem Global has run for global manufacturers over more than 20 years give a sense of the ceiling. On a document of roughly 200 pages, a little over 30,000 words, close to 90% of the volume lands in the 100% match or fuzzy match range, and the share written completely fresh because the library holds nothing for it stays under 10%. Those numbers reflect a long-accumulated TM working together with standard sentence management, and they vary with industry, product category, and how long the library has been in operation.

That number is also a defense. When a documentation budget comes under review, the team that can present cumulative savings from its reuse system negotiates from a different position than the team that cannot.

3.4 Supporting infrastructure: the file discipline underneath

A sentence library does not operate in a vacuum. The document files it points to have to be managed predictably. Four rules cover it.

A version notation standard

Separate draft notation from released notation. Internal review drafts run D01, D02. Released documents run Rev 1.0, Rev 2.0. Define the condition that converts a draft into a release, usually final approval. Post-release revisions increment the Rev number. What matters more than the notation itself is that the entire team uses exactly one notation.

Change notes

Create a standalone change record for every version capturing the author, the requester, and the location and substance of each change. This note pairs with the sentence history from 3.1. The sentence history answers “why is this sentence the way it is.” The change note answers “what changed in this version.” It is also the raw material for the delta report.

Naming conventions

Apply a consistent composition rule to folder names, file names, and image names. A file name composed as model_doctype_language_version (ABC-100_UG_EN_Rev1.0), and an image name composed as attribute_category_function (img_setting_display_brightness), lets a reader predict the contents from the name alone. Give a translated file the same name as its source with only the language code changed, so the version correspondence is visible in the name.

The real value of a naming convention runs deeper than convenience. In an organization where the whole team knows and follows the rule, a writer can be on vacation, on leave, or gone from the company and a colleague can still locate the file, understand what is in it, and pick up the work. The map of where everything lives moves out of one person’s head and into a rule the organization shares. Continuity in documentation work is decided by file names more often than by handover documents.

The effect grows with time. Files named by rule remain identifiable ten and twenty years later from the name alone. That matters when the certification history of a discontinued product has to be traced, when a team has to establish when and how a safety statement in an older model was changed, or when a recall or a product liability claim requires the company to identify exactly which manual revision shipped with a given unit. In a US litigation or CPSC reporting context, that identification is not optional. Twenty years of folders accumulated without a naming rule are, for practical purposes, twenty years of files the company does not have.

Date-based retention of incoming material

Engineering change requests, screen captures, specification sheets, and anything else received from other departments gets stored as received, in a folder keyed to the date of receipt. When a request is reversed or a dispute opens, this is the only way to establish what material the work was based on and when.

3.5 (Optional) Putting an app on top of the library

The system described so far is complete on a spreadsheet. As the library grows and the writing team expands, finding a sentence by remembering where it lives starts to strain. The next step at that point is not a CCMS. It is a lightweight lookup app sitting on top of the spreadsheet library that already exists, treating it as the database.

The app does not replace the library. It adds a lookup layer over it. The spreadsheet holding sentences, history, classification, and variant conditions remains the source of record, and the app provides keyword search, chapter filtering, and variant-condition lookup on top. Instead of scrolling a sheet, a writer calls up a sentence by search term and reads the source, the reference translation, the history, and the applicable conditions on one screen.

What this buys:

• No migration burden, because the spreadsheet assets accumulated in earlier phases carry over intact.
• Development and maintenance cost far below a CCMS-class system, because the scope is limited to search and filtering.
• A foundation for later expansion into a translation memory or a full content management system, because the data is already normalized at the sentence level.

The app is an option for improving findability. It is not a precondition for the reuse system this paper describes. It has to sit on top of registration criteria, governance, and history discipline that are already in place. Build the app first and the team gets faster access to data nobody organized.

4. A four-phase adoption roadmap

This system does not arrive fully formed. The four phases below are designed so that the output of each becomes the input of the next, and so that each phase delivers value on its own. Stopping partway does not waste what was already invested.

Phase 1. Sentence inventory (roughly 1 to 2 months)

Take one representative document, the most recent manual for a flagship product, break it into sentences, and mark each sentence for whether it also appears in other documents and whether it goes out for translation. Two things surface from that alone. The share of the document that is genuinely reuse-eligible becomes visible, and it usually runs higher than the team expected. The number of duplicate sentences saying the same thing in different words also becomes visible. Those figures are the business case for the phases that follow.

Phase 2. Library construction and standard designation (roughly 2 to 3 months)

Move the reuse candidates from the inventory into the structure from 3.1: document structure mirrored in sheets, one row per sentence, bilingual pairs, history fields. This is where the team has to decide which of several duplicate sentences becomes the standard. That decision is human work, and it would have been unavoidable even with a CCMS in place. Start the habit of recording the basis for each designation in the history field here.

Phase 3. Governance goes live (roughly 1 month, then ongoing)

Designate the librarian, fix the proposal form and the color convention, announce the batch cycle, and move safety and regulatory content onto its separate tier. What matters in this phase is running the first batch cycle for real. Do not spend the month perfecting the rulebook. Two or three cycles will expose the problems in the form and the interval, so leave the rules loose enough to adjust early.

Phase 4. Translation integration and measurement (roughly 2 to 3 months)

Starting with the next derivative model or revision project, submit translation as a delta report and agree match-rate-based billing with the translation partner. Calculating and reporting the savings on that first project is what establishes the reason for the whole system inside the organization. Once translation volume passes a threshold, evaluate migrating the bilingual library into a CAT tool TM.

Total elapsed time runs six months to a year depending on organization size. The workload is scoped so an existing documentation team can carry it alongside regular work with no dedicated headcount. In practice the bottleneck that determines the timeline is not effort. It is the standard designation decisions in Phase 2. Building a decision path that includes the person with authority, from day one, is what controls the schedule.

5. When to move to a CCMS

This methodology is a predecessor to a CCMS rather than a substitute for one. For an organization running a stable discipline-based system, the following signals accumulating are the point at which a CCMS deserves serious evaluation.

• Combinatorial explosion. Product lines, regional variants, and document types multiply until variant management no longer fits in spreadsheet columns. When variants routinely exceed two or three per sentence, the organization needs conditional publishing.
• Concurrent edit collisions. Enough people need to update the library that the batch cycle can no longer arbitrate conflicts.
• Output channel proliferation. The same content has to publish automatically to print, web, and embedded product help.
• Traceability becomes contractual. Regulated-industry certification makes system-level audit trails of content change a contract requirement or a certification requirement. For FDA-regulated devices in particular, design history file expectations push in this direction.

A CCMS implementation launched from that position has a low failure rate. The content is already organized at the sentence level, the standards are already designated, and the team already thinks in components. Migration becomes the transfer of an organized asset. Having run a reuse system without a CCMS turns out to be the most reliable preparation for buying one.

6. Closing

Content reuse is a discipline problem before it is a technology problem. The criteria that decide what becomes an asset, the limits on who can change an asset and through what procedure, the history left behind by every change, and the predictable file order that supports all of it. An organization with those four in place can structurally lower derivative documentation cost with nothing more than a spreadsheet. An organization without them will reproduce the same problems inside any system it buys.

Reduced to a single sentence, the asset comes from the designation rather than from the quality of the writing. Writing better sentences and designating a standard are two different jobs, and the one that moves cost is the second. An expensive system will not make that decision on the team’s behalf. The discipline of designating comes first. The tooling comes after.

Frequently Asked Questions