
Rewriting live selling scripts for a translated stream
Four kinds of Chinese live selling phrasing that break somewhere in the translation pipeline, why each one breaks, and what to say instead.

Script problems in cross-border streaming are seldom about translation accuracy. The more common situation is that certain phrasing is no longer a meaningful sentence by the time it has passed through recognition and synthesis. Changing translation engines does not help. The script itself has to change.
Four categories need rewriting rather than translating.
One: forms of address and collective pronouns
Chinese live selling leans hard on audience terms of address that build familiarity and push action while carrying almost no literal content. Rendered word for word, viewers receive a kinship term with no relationship to the situation.
A glossary cannot fix this category. Azure is explicit about the scope of its dynamic dictionary: the feature is safe only for compound nouns such as proper names and product names. Terms of address and interjections are not that, and forcing them in tends to produce a differently awkward fixed rendering.
Replace by function instead: to build familiarity, address the audience group directly; to push action, give the action as an instruction. This is a rewrite, and afterwards the two scripts are no longer sentence-for-sentence equivalents — which is exactly the line between localisation and translation.
Two: numbers, prices and countdowns
This category fails invisibly, because it breaks at the recognition layer rather than the translation layer.
Mainstream recognition services apply inverse text normalisation (ITN), converting spoken numbers into written symbolic forms. Azure’s documentation gives direct examples: spoken nine hundred dollars becomes $900 in the display text, and six forty five p m becomes 6:45 PM. The important sentence follows: the service performs this process and it is not configurable.
Two practical consequences:
- You do not control how a price is displayed. What appears in the caption is the service’s interpretation, not your phrasing.
- Faster and more slurred delivery makes it worse. Recognition has to segment the words correctly before normalisation can even apply. Get the segmentation wrong and everything after it is wrong too.
Countdowns are the extreme form of the same problem. A three-two-one call to action has almost no pause between the numbers, and that rhythm is the entire point of the line. By the time the pipeline has produced the translated audio, the window it was announcing has usually closed.
The fixes are all in the script:
- Give prices their own sentence, with pauses on both sides, rather than burying them mid-clause;
- Slow down for numbers — prices, sizes, discounts and stock counts;
- Do not expect countdowns to survive. State the instruction separately and in advance, and let the countdown itself live in the visuals and the original audio.
Three: promotion mechanics
Terms for spend-and-save thresholds, basket-topping, price adjustments after ordering and pre-order deposits are not hard to translate. The difficulty is that the mechanism often does not exist in the target market, so the output is literally correct and operationally useless.
The work here is triage rather than translation:
- Does this mechanism exist on the target platform? If not, cut the passage entirely instead of describing a button nobody can find;
- If it exists under a different name, use the target platform’s own official terminology, not a literal rendering;
- If it needs explaining, explain it as a sequence of actions rather than naming it.
Step 3 gets skipped the most. A domestic audience hears one word and reconstructs the whole flow; an overseas audience hears an unfamiliar noun followed by instructions with no context.
Four: wordplay and near-homophones
Puns break at the recognition layer. The recogniser emits the most probable word, not the ambiguity you intended, so by the time the translation layer sees the text, the pun has already collapsed into one literal reading. Wordplay cannot cross this pipeline, and there is no configuration that changes that.
Near-homophones carry a less obvious risk: the profanity filter. Azure’s recognition service defaults to Masked, replacing letters in words judged profane with asterisks, and Microsoft notes that it reserves the right to mask or remove any word it considers inappropriate regardless of your filter setting. Certain near-homophone phrasing can therefore turn into a row of asterisks in your captions without you ever being told.
Worth knowing alongside it: filler and repetition get removed. Recognition services commonly apply disfluency removal, stripping filler words and duplicated words. That is a gift for transcripts, but if your script uses repetition for emphasis, the emphasis is flattened out before translation ever sees it.
Everything else: two rewriting rules
Outside those four categories, nothing needs rewriting. Two rules are enough.
One thing per sentence. Synthesised audio plays serially, so a long sentence stretches both the segmentation wait and the playback time — the two largest components of end-to-end latency. Splitting a compound claim into two sentences measurably moves up the moment the audience hears it.
Nouns beat pronouns. Chinese live selling resolves “this one” and “it” visually, but translation works on text and never sees the picture. Worse, translated audio lags the original by several seconds, so by the time a viewer hears “it”, the host may already be holding the next product. Swapping pronouns back to product names costs a few words and removes an entire class of misunderstanding.
Both rules also improve recognition: shorter sentences segment more reliably, and specific nouns are what your glossary entries can actually match.
How to check the rewrite worked
Do not use back-translation. Translating into English and back into Chinese only tests the engine’s self-consistency, not whether your audience understands anything.
There is one check worth running: have someone from the target market listen to ten minutes of translated audio with no picture, then tell you what you are selling, what it costs, and how to buy it. If those three do not come back, the script has failed, and translation accuracy has nothing to do with it.
When no such person is available, the fallback is to print the translated transcript of those ten minutes, delete every pronoun, and see whether it still reads. Wherever it stops making sense is where your audience is being asked to guess from the picture — and by the time they hear the translation, the picture has moved on.
Frequently asked questions
- How should Chinese audience terms of address be translated?
- They should not be translated at all. Their job in a Chinese stream is to build familiarity and push action, and the equivalent in English is addressing the audience directly and giving a clear instruction — not any literal rendering of a kinship term.
- Why do prices come out wrong or oddly formatted?
- Most recognition services apply inverse text normalisation, converting spoken numbers into written symbolic forms, and Azure documents that this process is not configurable. Prices therefore have to be handled in the script by giving them their own sentence, slowing down, and repeating them when it matters.
- Won't shorter sentences sound abrupt?
- In a translated stream, sentence length is a comprehension issue rather than a style one. Synthesised audio plays serially, so long sentences stretch both segmentation wait and playback time, and second-language listeners carry a heavier load on long sentences to begin with.
- Can a glossary pin a catchphrase to one rendering?
- Generally no. Azure limits its dynamic dictionary to compound nouns such as proper names and product names. Catchphrases, filler words and verb phrases fall outside that scope, and forcing them into a glossary usually produces something stranger than the default.

