Post 3 in our series on localization skills for modern technical communicators
Every sentence you write is a brief to a translator. You may never meet them, never speak with them, and never see the language they work in. But the decisions you make at the keyboard, how long your sentences run, whether you reach for an idiom, whether you leave a term undefined, whether you write in the active or passive voice, shape the quality, speed, and cost of every translation your content will ever receive.
Writing for translation is not a separate skill you apply to content earmarked for multilingual markets. It is a discipline that makes all technical communication cleaner, clearer, and more precise. The habits that help a translator are the same habits that help a reader. But when translation is in the picture, the stakes for getting it wrong multiply with every language added to the pipeline.
This post is your practical guide to writing source content that translates well. Not because you’re handing off a problem, but because you’re preventing one.
Here is my poem to set the stage:
Write it clean and write it clear;
— CJ Walker and AI Pals
the translator’s ear is always near.
One muddled phrase, one borrowed slang:
a hundred languages feel the bang.
Why Source Quality Is a Business Decision
Before we get into the craft, let’s establish something that often gets missed in conversations about translation quality: the translator is not the last line of defense. You are.
It is worth pausing here to note that the localization pipeline involves more people than just the translator. Localization engineers prepare files for translation and reassemble them afterward. Desktop publishers reformat translated content to fit the target layout. Localization QA specialists test that translated content works correctly in context. Poor source quality creates problems for all of them, not just the person doing the linguistic work. In this post, “translator” refers specifically to the linguistic step; the broader team will feature in later posts in this strand.
Translation costs are typically calculated per word. But the real costs of poor source quality don’t show up in the word count. They show up in translator queries (questions raised when the source is ambiguous), in post-editing rounds (corrections required after machine translation produces nonsense from confusing input), in rework cycles (when a translated passage has to be redone because the source changed after translation began), and in localization testing failures (when a translated string breaks a UI because nobody accounted for text expansion).
Every one of those cost drivers is controllable at the source. A technical communicator who understands this is not just a better writer. They are a more valuable business partner.
The discipline has a name in the localization industry: translatability. Highly translatable content is unambiguous, consistent, culturally neutral, and structurally predictable. It moves through translation workflows faster, with fewer queries, at lower cost, and with higher quality in the target language. Building translatability into your writing practice is one of the highest-return investments a technical communicator can make.
The Core Principles of Writing for Translation
Write Short, Simple Sentences
This is the single most impactful change most technical communicators can make. Long, complex sentences with multiple clauses, embedded conditions, and dangling qualifiers are difficult for human translators to parse and produce poor results from machine translation engines.
A useful benchmark: aim for an average sentence length of 20 words or fewer. This isn’t about dumbing content down. It’s about removing the structural complexity that doesn’t add meaning and replacing it with clarity that does.
Compare these two versions of the same instruction:
Before: “Before proceeding to the next step, which requires administrator privileges that may not be available in all deployment environments, ensure that the configuration file has been saved and that all running processes have been terminated.”
After: “Save the configuration file. Terminate all running processes. The next step requires administrator privileges. Check that these are available in your deployment environment before continuing.”
The second version is easier to read in English. It is dramatically easier to translate into German, Japanese, or Arabic, where sentence structure, verb placement, and grammatical agreement rules differ significantly from English.
Use the Active Voice
Active voice sentences follow a Subject-Verb-Object structure that is predictable across most world languages. Passive voice inverts this structure, introduces ambiguity about who is performing the action, and creates translation challenges in languages that handle passive constructions differently from English.
“The system generates a confirmation email” is active, clear, and easy to translate. “A confirmation email is generated by the system” introduces unnecessary complexity. “A confirmation email will have been generated” is a translator’s puzzle that costs time and money.
There are four contexts where passive voice is genuinely appropriate in technical documentation, and it is worth knowing them clearly.
- When the actor is unknown or genuinely irrelevant.
“The error was logged at 14:32.”
Who or what logged it doesn’t matter to the user; the fact that it was logged is what’s relevant. Forcing active voice here (“The system logged the error at 14:32”) adds a subject that carries no useful information. - When the action performed on the object is more important than who performs it.
“The sample must be stored at 4°C.”
This is a requirement statement. Who stores it (the user, a technician, a lab assistant) is less important than the requirement itself. Passive voice here is actually the more precise construction. - When the action performed on the object is more important than who performs it.
“The sample must be stored at 4°C.”
This is a requirement statement. Who stores it (the user, a technician, a lab assistant) is less important than the requirement itself. Passive voice here is actually the more precise construction. - When regulated or scientific contexts require established formulations.
“It is recommended that…” and “The device shall be calibrated before use” are standard formulations in regulatory, standards, and safety documentation.
Rewriting them into active voice can introduce ambiguity about who the recommendation applies to, and may deviate from required phrasing in regulated industries.
This is an important distinction for technical communicators working in aerospace, medical devices, manufacturing, and other regulated sectors: passive voice in those contexts is not a bad habit. It is often a professional and legal requirement.
In general writing, passive voice is discouraged because it can obscure accountability and reduce clarity. “Mistakes were made” is evasive in a news article. In technical documentation, the objection is more specific: passive voice used out of habit in instructional contexts creates ambiguity about who does what, and in safety-critical documentation, that ambiguity is unacceptable. The principle is not “never use passive voice.” It is “use passive voice deliberately, and use active voice everywhere else.”
Be Consistent with Terminology
Terminology inconsistency is one of the most expensive problems in localization. When the same concept is referred to by different terms across a document or documentation set, translators must make independent decisions about how to handle each variant. Those decisions may not be consistent with each other, or with the decisions made by translators working in other languages, or with the decisions encoded in the translation memory from previous projects.
The result is terminology drift: a product documentation set where “user account,” “account profile,” “user profile,” and “customer account” all appear, each potentially translated differently, creating a fragmented and confusing experience for users in every target language.
Choose one term for each concept and use it everywhere. This is the source-side discipline that terminology management systems (covered in Post 5) are designed to enforce at scale. At the writing level, it starts with a simple commitment: decide what you call something, and call it that, every time.
Avoid Idioms, Metaphors, and Cultural References
Idioms are the most visible offender in translatability discussions, and for good reason. “Hit the ground running,” “touch base,” “boil the ocean,” “low-hanging fruit”: these phrases are so embedded in professional English that many technical communicators use them without noticing. Translators notice immediately.
Some idioms translate literally into nonsense. Others translate into something that sounds odd, informal, or inappropriate in the target culture. The safest and most professional approach is to eliminate them entirely from technical documentation and replace them with plain, direct language that conveys the actual meaning.
The same applies to cultural references, humor, and analogies that depend on shared cultural context. A reference to a sporting event, a television program, or a national custom that works perfectly for a US English audience may be completely opaque to a translator working into Korean, or actively alienating to a reader in a market where that cultural reference carries different associations.
Technical communication at its best is clear, direct, and purposeful; those are qualities that serve readers in any language. The point is that expressions borrowed from informal speech, regional culture, or creative writing tradition create friction in translation that plain, precise language does not. Removing idioms is not a loss; it is a discipline that sharpens the writing.
Watch for Ambiguity
Ambiguous sentences are translation problems waiting to happen. English tolerates a great deal of ambiguity that other languages do not; pronoun reference, modifier placement, and prepositional attachment are all common sources of ambiguity that translators must resolve, often by guessing.
Consider: “Press the button to confirm the setting before it resets.” What resets: the button, the setting, or the system? In English, a reader might infer the answer from context. A translator working without visual context for the UI must make a choice, and in some languages that choice affects the grammatical form of the entire sentence.
Resolving ambiguity costs translator time and introduces the risk of inconsistent resolution across languages. The fix is almost always simple: rewrite the sentence so only one interpretation is possible. “Press the button to confirm the setting. The system resets after 30 seconds if you do not confirm.”
Avoid Nominalization
Nominalization is the habit of turning verbs into nouns: “perform an analysis” instead of “analyze,” “make a determination” instead of “determine,” “provide a recommendation” instead of “recommend.” It is extremely common in technical and corporate writing, and it creates two problems for translation.
First, nominalizations add word count without adding meaning, increasing translation costs directly. Second, they often produce ambiguous sentence structures where the verb-like noun is grammatically unclear in its relationship to the rest of the sentence. Many languages handle nominalization very differently from English, and what reads as formal and authoritative in English can sound stilted or unnatural in translation.
Prefer verb forms over noun forms wherever possible. “Analyze the output” is shorter, cleaner, and more translatable than “perform an analysis of the output.”
Handle Numbers, Units, and Formats Carefully
Numbers, units of measurement, date formats, and currency symbols all require localization decisions that should be flagged clearly in the source. As established in Post 2, hardcoded formats create downstream problems. In the context of writing for translation specifically, there are additional considerations.
Avoid spelling out numbers inconsistently: choose a convention (numerals or words) and apply it consistently. Avoid mixing metric and imperial units in the same document without explicit conversion guidance. Avoid time formats that are ambiguous across locales (12-hour versus 24-hour clock, AM/PM conventions). And always mark any format that will require localization with a clear comment or flag in your source file so the localization engineer can handle it correctly.
What a Translator Sees When They Open Your File
It helps to spend a moment in a translator’s position. When a professional translator receives a technical documentation project, they are typically working in a computer-assisted translation (CAT) tool that presents the source text in segments, usually sentence by sentence. They translate each segment individually, with access to translation memory (previously translated segments from earlier projects) and a termbase (the agreed glossary of approved translations for key terms).
This workflow has important implications for how you write.
Segments are translated without surrounding context. A translator working on segment 47 of a 300-segment document may not have easy access to segment 12, where a term was first defined. This means every segment should be as self-contained as possible. Pronoun references that rely on context from several paragraphs back (“as noted above,” “the aforementioned setting”) create ambiguity that the segmented workflow makes harder to resolve.
Translation memory matches on segment boundaries. If you reuse content across documents, consistent sentence structure and wording maximizes translation memory leverage, meaning previously translated segments are automatically proposed by the CAT tool and accepted without retranslation cost. Variable, creative rephrasing of the same instruction across multiple documents destroys this leverage entirely.
Queries slow the workflow for everyone. When a translator encounters something they cannot resolve confidently, they raise a query. Each query requires a response from the project manager or the source content owner, introduces a delay, and adds a coordination cost. Queries are often caused by exactly the source quality issues covered in this post: ambiguity, inconsistent terminology, undefined acronyms, and culturally specific references.
Understanding this workflow is not just empathy-building. It is professional knowledge that makes you a better source-content author and a more effective collaborator with your localization team.
Real-World Scenarios
The instruction that meant two things.
A software company’s installation guide included the instruction: “Select the components you want to remove and click OK.” In English, “remove” was understood by most readers as “deselect” (remove from the installation selection). When translated into German, the translator chose a term closer to “delete” or “uninstall.” Users following the German documentation removed installed components they needed. The source sentence was ambiguous. The translation made that ambiguity consequential.
The idiom that confused a market launch.
A technology company’s product release notes included the phrase “this update addresses several pain points raised by customers.” The term “pain points” translated into a target Asian language in a way that suggested physical discomfort. Customer support in that market received confused inquiries about whether the product was causing hardware problems. A single idiomatic phrase, removed and replaced with “issues raised by customers,” would have prevented the confusion entirely.
The inconsistent term that multiplied across languages.
A documentation team used “workspace,” “project space,” “working environment,” and “dashboard” interchangeably to refer to the same UI element across different sections of their product documentation. Each term was translated independently, producing four different terms in each target language. Users switching between help articles encountered what appeared to be references to four different UI elements. The fix required a terminology audit of the source, a decision on a single preferred term, and re-translation of affected segments across all languages. The cost was significant. The cause was inconsistency in the English source.
Common Pitfalls and How to Avoid Them
| Pitfall | What Goes Wrong | How to Avoid It |
|---|---|---|
| Long, multi-clause sentences | Translators struggle to parse structure; machine translation produces poor output | Keep average sentence length to 20 words or fewer; break complex sentences into shorter units |
| Passive voice overuse | Ambiguity about the actor; grammatical challenges in many target languages | Default to active voice; use passive only when the actor is genuinely unknown, when the action matters more than who performs it, or when regulated contexts require it |
| Terminology inconsistency | Translators make independent decisions; target-language versions use different terms for the same concept | Establish a preferred term for each concept and enforce it throughout the source |
| Idioms and cultural references | Translate literally into nonsense, or carry unintended cultural associations | Replace idioms with plain language equivalents; avoid culturally specific humor and analogies |
| Ambiguous pronoun reference | Translators guess; different languages resolve ambiguity differently, producing inconsistent results | Rewrite ambiguous sentences so only one interpretation is possible |
| Nominalization | Adds word count; creates grammatically ambiguous structures in translation | Prefer verb forms over noun forms wherever possible |
| Undefined acronyms | Translators cannot translate what they cannot identify | Define every acronym on first use; provide a glossary for translators |
| Embedded locale-specific formats | Dates, numbers, and units require localization work that wasn’t flagged | Mark all locale-sensitive content clearly; use variables where possible |
Career Opportunities
Writing for translation is a skill that looks deceptively simple from the outside and reveals its depth quickly in practice. Technical communicators who develop this skill consciously and can demonstrate its business impact are consistently valued above peers who write well but haven’t made the localization connection.
Senior Technical Communicator (Global)
Many organizations distinguish between general technical communicator roles and those with explicit responsibility for source content quality in multilingual pipelines. Demonstrating writing-for-translation discipline is one of the clearest ways to move into the global-focused variant of a senior individual contributor role.
Localization-ready Content Designer
As introduced in my previous post, this role owns source content architecture across a documentation set. Writing for translation is the foundational craft skill this role is built on; the structural and stylistic discipline that makes everything else in the localization pipeline work.
Content Quality Lead
In larger documentation teams, content quality roles increasingly include translatability metrics alongside readability and accuracy. Technical communicators who can define, measure, and enforce writing-for-translation standards are natural candidates for these roles.
Localization Consultant
Independent consultants who specialize in source content audits, writing-for-translation training, and localization readiness assessments are in steady demand from organizations scaling into new markets. This is a well-established freelance path for technical communicators with strong localization expertise.
The business case for this skill is straightforward and quantifiable: organizations that invest in source content quality consistently report lower per-word translation costs, faster turnaround times, higher translation memory leverage rates, and fewer post-translation corrections. Those metrics are yours to own.
A Light Learning Path
Weeks 1 to 2: Audit your own writing.
Take a recent documentation project and apply the principles in this post as a checklist. How long are your sentences on average? How many idioms appear? How consistently is your terminology used? The audit itself builds the habit.
Weeks 3 to 4: Learn to read like a translator.
Spend time with a free CAT tool (OmegaT is a well-regarded open-source option) to understand how translation memory and segmentation work in practice. You don’t need to translate anything; the goal is to see your source content the way a translator sees it.
Month 2: Build a personal style guide for translatability.
Document your preferred terms, your sentence length conventions, your list of banned idioms, and your format handling rules. Apply it to a new project and measure the difference in translator query volume if you have access to that data.
Month 3 onward: Connect to the broader strand.
Writing for translation connects directly to the skills in Post 4 (Controlled Language and STE), which takes the principles in this post and formalizes them into an internationally recognized standard; and to Post 8 (Terminology Management), which provides the infrastructure for enforcing the terminology consistency that writing for translation requires at the source.
Your Next Career Move
The principles in this post are immediately applicable. You don’t need new tools, a new workflow, or sign-off from a manager to start writing more translatable content. You need awareness and discipline, and both start with the next sentence you write.
If you want to formalize your technical communication foundations and understand how writing quality connects to global content strategy, Fundamentals of Modern Technical Communication, Part 3 by Ben Woelk and Jennifer Goode is a strong starting point, with a specific focus on designing content for local, national, and international audiences.
For teams looking to operationalize writing-for-translation standards at scale, An Introduction to Content Operations by Rahel Bailie covers the processes and governance structures that turn individual good practice into team-wide content quality.
If your organization is ready to take source content quality seriously as part of a broader AI-readiness and localization strategy, The Clarity Lab can help. Firehead’s content AI-readiness consulting brings together structured content expertise, localization preparation, and knowledge architecture to build the foundation your global and AI ambitions require. Get in touch to start that conversation.
Firehead works with technical communicators at every stage of this journey; from those writing their first multilingual documentation to experienced practitioners stepping into global content leadership roles. Browse our current opportunities on the Firehead Job Board and explore all our courses at the Firehead Training Academy.
Subscribe to Ignite!, our newsletter, for industry news, skills learnings, and new course announcements: https://firehead.net/#newsletter
Firehead. Visionaries of potential.
All changes incorporated, CJ. Ready for your Google Doc!
