Daniel sent us this one — he's been thinking about the gap between how we write and how our words land after machine translation. You write a clear RFQ in English, you send it to a supplier in Shenzhen, and what they read is a mangled version where tolerances got swapped, quantities went missing, and a phrasal verb turned into something about picking up a truck. Who's actually at fault here?
Almost always the writer. And I say that as someone who's spent years reading medical literature that got run through translation — the problem isn't that the machine is stupid. It's that we keep handing it sentences with built-in landmines and then acting surprised when they detonate.
The landmine image works. You bury ambiguity in a perfectly fluent English sentence, the machine steps on it, and the Chinese reader is left staring at something that looks grammatical but means something entirely different.
Here's what makes this urgent right now — AI translation has gotten so good at producing natural-sounding output that we've stopped being suspicious of it. GPT-4o, DeepL, Google Translate — they write sentences that read like a human wrote them. So when they get something wrong, the error is camouflaged. It reads like a coherent specification that just happens to be wrong.
Which is worse than an obvious error. An obvious error you flag and clarify. A fluent error you ship the parts.
There was a study from the Localization Industry Standards Association — LISA — back in twenty twenty-four. They ran unedited B2B technical text through English to Chinese and back to English. About thirty percent meaning loss. Not fluency loss — the sentences came back sounding fine. Specifications that just vanished or mutated in transit.
Thirty percent is not a rounding error. That's a full-blown supply chain risk.
That's the thing nobody talks about when they pitch AI translation as "seamless." The seamlessness is the danger. A clunky translation puts you on alert. A smooth one puts you at ease while quietly changing "finish: smooth, no sharp edges" into something the supplier reads as an aesthetic preference instead of a burr-free requirement.
The episode Daniel's asking for is essentially: how do you write source text that survives the machine? What are the rules for making your English translation-proof?
Translation-safe, not translation-proof. The goal isn't bulletproof — it's eliminating the need for the machine to guess. Every ambiguous pronoun, every passive construction, every phrasal verb is a guess the MT system has to make. And it will guess. It has to. It can't ask clarifying questions the way a human translator can.
That distinction feels important. Most writing-for-translation advice assumes a human translator who can email you and say "does this refer to the bracket or the panel?" Machines don't do that.
They don't. They resolve the ambiguity statistically based on training data and move on. And in technical documents — RFQs, specs, tolerances — statistical guessing is not good enough. A fifty-one percent confidence on a pronoun reference is a coin flip with money attached.
We're going to cover universal best practices first — rules that apply whether your text is heading into Chinese, German, Japanese, whatever. Then we drill into English-to-Chinese specifically, because that's the manufacturing pair that matters for most of Daniel's audience, and it has its own structural nightmares.
Chinese is a uniquely hard target for English MT. It lacks grammatical number, it doesn't mark tense the way English does, it has no direct equivalent for phrasal verbs, and its relative clause structure can turn English modifiers into long chains of the particle "de" that MT over-generates. But we'll get there.
Before we do — I want to sit with the failure scenario for one more beat. Walk me through a real case. What actually happens when an RFQ goes wrong through translation?
Injection-molded parts. The English spec said "Finish: smooth. No sharp edges." The Chinese translation came back as — and I'm reading the back-translation — "surface smooth, no sharp edges." The supplier interpreted "smooth" as an aesthetic finish quality, not a functional burr-free requirement. Parts arrived with burrs. They were smooth burrs. Technically a smooth surface with sharp edges. The spec didn't say "all edges must have a radius of at least zero point five millimeters, no burrs or flash allowed." It relied on the reader interpreting "smooth" and "no sharp edges" as connected requirements.
That's almost poetic.
It's expensive poetry. And the fix is what we're going to spend this episode building toward — writing that doesn't depend on the reader making the same interpretive leap you made when you wrote it.
The core problem is that MT systems preserve syntax better than semantics. The sentence structure survives, but the meaning is fragile.
And the fragility is worst exactly where human writers feel most fluent — pronouns, passives, idiomatic phrasing, long sentences with multiple dependent clauses. The things that make English sound natural to an English reader are the things that break hardest in translation.
Which means writing for translation is almost the opposite of writing for style.
That's where people push back. They say "this sounds like I'm writing for a child." But you're not dumbing down. You're increasing precision. "Attach the bracket to the panel. The bracket must be painted" is not dumber than "Attach the bracket to the panel. It must be painted." It's more precise. The first version removes a guess. The second version forces one. And the cost of a wrong guess in a manufacturing context is measured in tooling changes, rejected lots, and air freight.
Where do we start with the rules? What's the first thing someone should fix in their writing if they know it's heading into MT?
That's the single biggest source of ambiguity in machine translation, and it's the easiest thing to fix once you start looking for it. Every "it," "they," "this," "that," "which" — every one of those is a resolution problem. The MT system has to figure out what the pronoun refers to, and it does that statistically by looking at surrounding nouns and picking the most likely candidate based on training data. In technical text, the most likely candidate in the training data might not be the right candidate in your sentence. The fix is to just not use the pronoun. "Attach the bracket to the panel. The bracket must be painted." No guess required.
That feels almost too simple to be worth stating, but I can think of a dozen RFQs I've seen that are full of exactly that pattern.
It's everywhere. And relative pronouns are worse. "The sensor sends a signal to the controller, which then adjusts the valve." What adjusts the valve — the sensor or the controller? English syntax says the nearest antecedent is "controller," but MT doesn't always parse that correctly, especially across language pairs where relative clause attachment works differently.
The universal rule would be: if a sentence contains a pronoun, replace it with the noun it refers to. Even if that means repeating the noun.
Repetition in the source language is clarity in the target language. The W3C — the World Wide Web Consortium — has internationalization best practices that specifically call this out. They recommend keeping sentences under twenty-five words and eliminating ambiguous pronoun references. These are web standards people, not translators, and they're saying this because they know content gets machine-translated billions of times a day.
Twenty-five words as the ceiling. That's shorter than most people write naturally.
Every clause boundary is a point where the MT system has to re-establish dependencies — what modifies what, what refers to what. The more clauses you stack, the more opportunities for the system to drop or misparse a dependency. Short sentences have fewer internal boundaries. Fewer things to break.
Pronoun elimination and sentence length are kind of the same intervention from different angles. Both are about reducing the number of resolution problems the machine has to solve.
And the third universal rule builds on the same logic — controlled vocabulary. Pick one term per concept and stick with it. Don't say "start" in one sentence, "begin" in the next, and "commence" in the third. Those all map to different Chinese words, and the MT system might not realize they're supposed to mean the same thing. TAUS — the Translation Automation User Society — recommends a term base with no more than one term per concept. If you use "fastener" and "bolt" and "screw" interchangeably, the Chinese reader gets three different translated terms and has to figure out whether you're talking about three different things or one thing.
Which in an RFQ is a disaster. "Are these three separate line items or one part with three names?
The supplier won't ask. They'll quote what they think you want, and you'll find out about the misunderstanding when the shipment arrives.
The universal rules so far: kill pronouns, cap sentences at twenty-five words, lock your vocabulary to one term per concept. What about passive voice?
Passive voice is dangerous for MT because it omits the agent. "The bolt should be tightened to fifteen Newton-meters.With what tool? English uses passive voice to sound objective and formal, but it strips out the information that MT systems need to produce accurate translations in languages that mark agency differently. Chinese doesn't have a direct passive equivalent that works the same way. The Chinese passive — the "bei" construction — often carries a negative connotation, like something unfortunate happened. So MT systems have to restructure the sentence, and that restructuring introduces ambiguity. The active rewrite — "Tighten the bolt to fifteen Newton-meters" — gives the MT system a clear subject-verb-object structure that maps more cleanly.
"tighten the bolt" instead of "the bolt should be tightened." That's not just clearer for MT — it's clearer for everyone.
That's the thing that keeps coming up. Writing for MT clarity is writing for human clarity. The same text that survives translation better also reads better to a tired engineer at eleven PM who's skimming your spec. There's no tradeoff. You're not sacrificing readability for translatability. You're improving both.
Which addresses the "dumbing down" objection head-on. You're not making the text simpler. You're making it more precise.
Precision is the through-line. Everything we're going to talk about — the universal rules, the Chinese-specific traps, the checklist at the end — it all comes back to removing guesswork. Every ambiguity you leave in the source text is a decision you've delegated to a statistical model that has no context about your parts, your tolerances, or your supply chain.
That's the answer to Daniel's framing question. Who's at fault when the translation goes wrong? The person who delegated the decision.
That's really the shift in mindset that separates translation-safe writing from translation-brittle writing. A human translator reads your ambiguous sentence and thinks "I should ask about this." An MT system reads it and — well, doesn't think, it just resolves. And moves on.
The asymmetry is baked in. Human translators have a clarification loop. Machines have a confidence score and no way to surface it to you.
That's the part most writing-for-translation advice misses. The standard localization guides — W3C, TAUS — they were largely written with human translators in mind. They assume a human will catch what the machine misses and can send a query back to the author. Whereas Daniel's scenario — sourcing from China, writing an RFQ, hitting send — there's no human translator in the loop at all. The supplier is pasting your English into Baidu Translate or DeepL, and the output is what they quote against. The LISA study I mentioned wasn't testing a professional translation pipeline. It was testing exactly this scenario. English in, MT out, no human in between.
When we talk about "translation-safe" versus "translation-brittle," the distinction is: does this sentence contain anything that forces the MT system to make a choice it can't verify? A pronoun reference, a passive construction with a missing agent, a phrasal verb with multiple meanings, a long dependency between clauses. Each of those is a decision point where the system guesses. A brittle text looks fine in English because your human brain resolves all the ambiguity automatically. But the MT system doesn't have your context. It has statistical patterns from training data.
The brittleness is invisible to the writer. You have to learn to read your own writing as if you don't know what you meant. Which sounds absurd, but it's a trainable skill. And that's really what we're going to build toward in the second half — specific techniques for English-to-Chinese where the structural differences between the languages amplify every one of these problems.
You mentioned earlier that Chinese is a uniquely hard target. Before we get to the specific rules, give me the thirty-second version of why.
Three structural mismatches. One, Chinese doesn't mark grammatical number — "screw" and "screws" are the same word. So if your English says "insert the screw," the Chinese reader doesn't know if it's one or many unless you say so explicitly. Two, Chinese has no direct equivalent for English phrasal verbs — "set up," "break down," "plug in" all require different single-word verbs depending on context. Three, Chinese relative clauses stack differently than English, so an English sentence with "that" or "which" can turn into a long chain of the particle "de" that MT systems over-generate into near-gibberish.
The universal rules get you part of the way, but English-to-Chinese adds a whole extra layer of traps.
It's the most common B2B manufacturing translation pair in the world. If you're sourcing parts, you're almost certainly dealing with this specific language pair. But the universal principles come first — they're the foundation. The Chinese-specific rules are adjustments on top of that foundation.
You said something earlier I want to pull on — that MT systems resolve pronouns statistically, not logically. What's actually happening under the hood? Why can't a system that can write a sonnet figure out what "it" refers to?
Because it's not reasoning. It's doing something closer to pattern completion. The model has seen billions of sentences where a pronoun follows a noun, and it's learned that in most cases the pronoun refers to the most recent compatible noun. But "most cases" is not "this case." And technical text is full of edge cases where the statistical default is wrong. It's not that the MT system is confused. It's confident. It's confidently picking the wrong referent. A confused system might produce garbled output you'd notice. A confident system produces "the panel must be painted" and you paint the wrong part.
The controlled vocabulary point connects here too. If you use "fastener," "bolt," and "screw" interchangeably, you're confusing the MT system's statistical model before the reader even sees it. The MT system treats them as three separate terms and translates each one independently. The Chinese reader sees three different terms and reasonably assumes you're specifying three different parts.
Don't get creative. That might be the unofficial subtitle of this episode. And it applies to measurements and dates too. ISO 8601 — year-month-day, like twenty twenty-six dash zero four dash zero three — eliminates the question of whether "three slash four" is March fourth or April third. MT systems propagate ambiguity. They don't standardize dates for you. Same logic with units. Spell out "Newton-meters" instead of just "Nm" because MT systems sometimes drop unit abbreviations. "Fifteen Nm" becomes "fifteen.The supplier won't ask — they'll assume millimeters or centimeters or whatever their default is.
"fifteen Newton-meters" survives translation. "Fifteen Nm" might not.
That's a two-second fix at the writing stage that prevents a two-week delay at the clarification stage. The cost of fixing ambiguity in the source text is near zero. The cost of fixing it after translation is measured in time, money, and sometimes scrapped production runs.
Let me push on something. You said there's no tradeoff between MT clarity and human readability. But I've read technical documents written to these rules, and they do sound different. The rhythm is off.
They sound different from literary prose, absolutely. But technical documents aren't literary prose. An RFQ is not a novel. The reader isn't there for the rhythm — they're there to extract specifications accurately, fast, under time pressure. For that task, repetition is a feature. "The bracket must be steel. The bracket must be painted. The bracket must be shipped flat." The repetition tells the reader exactly where to look, exactly what applies to what. No scanning back up the paragraph to figure out what "it" referred to.
The choppiness is actually scannability.
It's scannability. And here's where the English-to-Chinese specifics get interesting — it's structurally closer to how Chinese technical writing already works. Chinese favors shorter clauses, topic-comment structure, explicit repetition of subjects. So writing for MT into Chinese produces English that's already halfway to Chinese prose structure. When you break your English into shorter sentences, you're pre-chunking the information in a way that maps more naturally to the target language. The MT system has to do less restructuring. Less restructuring means fewer opportunities to break things.
The twenty-five-word rule from the W3C isn't arbitrary. It's about minimizing the number of clause-level restructuring operations.
A twenty-five-word English sentence might have two or three clauses. A fifty-word sentence might have six. The MT system has to parse all six, figure out the dependencies, then rebuild the whole thing in Chinese syntax where the clauses might need to be reordered or restructured around topic-comment instead of subject-predicate. The complexity compounds. Two clauses might have one dependency to track. Six clauses might have fifteen. Each one is a guess. And the guesses multiply.
Those universal rules get you maybe eighty percent of the way. But English-to-Chinese has its own special set of traps. The first one — Chinese doesn't mark grammatical number. "One screw" and "five screws" are both just "luósī.
If your English text says "Insert the screw into the hole," the Chinese reader genuinely cannot tell if you mean one screw or fifty. There's no plural marker, no article, no verb agreement to signal quantity. The fix is brutally simple: always specify quantity explicitly in the same clause. "Insert one screw into each hole." "Insert five screws into each bracket." This gets worse with mass nouns. "Apply adhesive" — how much? The Chinese reader needs that specified because the English didn't encode it.
What about phrasal verbs?
This one is pervasive. English is packed with phrasal verbs — "set up," "break down," "pick up," "plug in." Chinese has no equivalent structure. Each phrasal verb has to map to a specific single-word Chinese verb that varies by context. "Set up the machine" is "ānzhuāng" — install. "Set up the parameters" is "shèzhì" — configure. If your RFQ says "Set up the device and set up the software," the MT system has to figure out which "set up" means which. The fix is to replace them with single-word verbs. "Install the machine. Configure the parameters." "Break down" becomes "disassemble" or "analyze." "Plug in" becomes "connect." One word, one meaning, no particle ambiguity.
I'm starting to see why the universal rules alone aren't enough. The pronoun fix and the short-sentence fix don't catch phrasal verbs at all.
They don't. And the next Chinese-specific trap is even more structural — the "de" particle explosion. In Chinese, "de" links modifiers to nouns, similar to "that" or "which" in English relative clauses. The problem is that MT systems over-generate these chains. If your English has nested relative clauses — "the bracket that attaches to the frame that supports the panel that houses the sensor" — the Chinese output becomes a long string of "de de de de de" that is nearly unreadable. The solution: break them completely. "The bracket attaches to the frame. The bracket must be steel." Two sentences, no relative clause, no "de" chain.
This is where you get pushback on style again. "The bracket attaches to the frame. The bracket must be steel." That sounds like a children's book.
It sounds like a children's book to an English ear. To a Chinese reader working through MT, it sounds like a clear specification. And that's the audience that matters. The English version is not the product. The Chinese version is the product. Write for the product.
That's a reframing worth sitting with. The English is an intermediate artifact. The Chinese is what actually gets read.
Once you internalize that, a lot of the stylistic resistance melts away. You're not writing English prose. You're writing input for a translation pipeline. The output is what matters.
What about the cultural dimension? I've heard people say that Chinese business communication is more indirect, and that an English RFQ that's too direct can come across as rude. But everything we're saying pushes toward more directness.
This is a real tension, and I think a lot of the advice on this is wrong. In B2B manufacturing specifically, Chinese suppliers want explicit, numbered, unambiguous requirements. They don't want to guess what you meant and then eat the cost of a misunderstanding. The solution is structural — separate the politeness from the precision. Use a polite framing sentence at the top — "We appreciate your careful review of these specifications" — and then follow it with bullet-point clarity. The framing carries the relationship. The bullets carry the precision. They don't interfere with each other.
Last Chinese-specific trap — measurements.
This one is practical and surprisingly common. Chinese manufacturing uses metric. But a lot of legacy specs still use inches and fractions. If your English text says "half-inch bolt," the MT system sees a fraction — "one slash two" — and has to render it in Chinese script. Fractions don't have a clean equivalent in Chinese typography. They often get mangled or dropped entirely. The fix: convert everything to metric and write as decimals. "Twelve point seven millimeter bolt." No fraction, no ambiguity, the unit is spelled out, and it's in the measurement system your supplier actually uses.
That's not a translation fix. That's a pre-translation fix. You're changing the source content to match the recipient's world.
That's really the meta-principle behind all the Chinese-specific rules. Don't make the MT system do cultural translation on top of linguistic translation. Give it content that's already in the right units, the right level of explicitness, the right clause structure. The less transformation the system has to do, the less it can break.
The five Chinese-specific traps are: number ambiguity, phrasal verbs, "de" chains from relative clauses, the directness-versus-politeness tension, and measurement unit mismatches. And they compound. A sentence that has a phrasal verb, an unmarked quantity, and a relative clause — "Set up the brackets that attach to the panel" — is three failure points in nine words.
Any one of them wrong, and the specification is corrupted. And across a supply chain, if your RFQ has fifty line items and each one has an average of two ambiguity points, you've baked a hundred guesses into the document. The probability that all hundred are correct is essentially zero.
Which brings us back to Daniel's original question — how do you write so the translation survives? The answer is: you remove the guesses.
The checklist writes itself at this point. Five things to do before you hit send on anything that's getting machine-translated. One, replace every pronoun with the explicit noun it refers to. Two, convert passive voice to active. Three, break any sentence over twenty words. Four, swap phrasal verbs for single-word verbs. Five, specify quantities and units explicitly in every clause.
Run those five checks, and you've eliminated maybe ninety percent of the guesses an MT system would otherwise have to make. The remaining ten percent are language-pair-specific things — like the "de" chains and measurement conversions we covered — but the universal five get you most of the way.
What I like about that list is you can actually do it. You open your RFQ, you scan for "it" and "they" and "which," you look for "should be" and "must be" constructions, you count words per sentence, you hunt for "set up" and "break down" and "pick up." It's mechanical.
The mechanical nature of it means you can automate part of it. Before you send a document, run it through a pre-editing pass with an LLM. Use a prompt like "Rewrite the following text for machine translation clarity. Replace all ambiguous pronouns, convert passive to active voice, break long sentences, and specify all quantities explicitly." But don't trust the output blindly. The LLM will catch maybe eighty percent of the problems, but it'll also introduce its own errors. You review the output. You don't delegate the final check.
The LLM is a first pass, not a final pass. It surfaces problems you might miss, and then you verify.
The verification step is where the real -skill comes in — learning to read your own text through the eyes of an MT system. There's a training technique that works: back-translation. Take your English text, run it through MT into Chinese, then translate the Chinese back to English using a different MT system. Then compare the back-translation to your original.
The gaps are where your ambiguity lives.
If your original said "Attach the bracket to the panel. It must be painted" and the back-translation says "Attach the bracket to the panel. The panel must be painted" — you just found a pronoun resolution failure. The MT system guessed "panel." Your Chinese reader saw "panel." You meant "bracket.
That's a concrete, testable workflow. Write, pre-edit with an LLM, review, back-translate, compare, fix the gaps. It adds maybe ten minutes to the document.
Ten minutes on the front end. Versus weeks of clarification emails, or a shipment of parts with smooth burrs. The asymmetry is absurd. And yet almost nobody does it.
Because the English reads fine. That's the trap we keep circling. The document looks done. It's only when you see the back-translation that you realize what the Chinese reader actually received.
That's the one thing I'd want every listener to take away. Next time you write an RFQ, spend ten minutes on pre-editing. Run the five checks. Do the back-translation. It will save you weeks of clarification emails and — depending on the order size — potentially tens of thousands of dollars in rework.
The question I keep coming back to is whether all of this eventually becomes obsolete. GPT-five, Gemini two point oh — these models are getting better at resolving ambiguity from context. Do we reach a point where the machine just figures out what you meant?
I'm skeptical. Not because the models won't improve — they will. But because the failure mode shifts rather than disappears. Right now the problem is dropped references and mangled phrasal verbs. In a more capable system, the problem might be hallucinated specifications. The model is so confident it fills in a tolerance you never wrote.
That's exactly the worry. A dumber MT system produces an obvious error you catch. A smarter one produces a plausible-sounding specification that's wrong in a subtle way. "The bracket must be steel" becomes "The bracket must be stainless steel" because the model learned that brackets in similar contexts are usually stainless. It's not mistranslating — it's adding.
Which is harder to detect than a dropped word.
And the real-time voice translation piece makes this even weirder. You've got earbuds on a factory floor, an engineer in Shenzhen is speaking Mandarin, you're hearing English in real time. The system has to commit to a translation before the sentence is finished. If the speaker pivots mid-sentence, the early translation might already be wrong and the listener heard it.
The clarity practices shift from writing rules to speaking rules. No mid-sentence corrections.
"The bracket is steel. " That's not how humans naturally talk. But it might be how we have to talk when every word is being translated in real time with no backspace key.
Which means this whole discipline we've been describing — writing for MT — is really the first wave of a bigger shift. We're learning to communicate with the machine as an intermediary, not just a conduit.
The intermediary is not neutral. It reshapes what passes through it. The question isn't whether these best practices become obsolete. It's what new practices we'll need when the failure pattern change.
The -skill is adaptability. Learning to spot where the machine might guess wrong, whatever form that guessing takes.
That's a good place to land. If you found this useful, share it with your supply chain team — the ten-minute pre-edit might save someone a very expensive phone call. Next episode, we're digging into the hidden costs of Incoterms you didn't know you were paying.
Thanks to Hilbert Flumingtop for producing. This has been My Weird Prompts. Find us at my weird prompts dot com.
Or email the show at show at my weird prompts dot com. We'll be back next week.
