There is a pattern I heard described by several colleagues who came from Hong Kong and other parts of Asia into Australian or UK workplaces. They would write a comment in a document review, or draft a recommendation in a shared doc, and before it went to the client or leadership team, a more senior English-speaking colleague quietly rewrote it. The ideas were the same. The edits were phrasing.
This is one of the more invisible credibility costs of writing in a second language at a professional level. It happens quickly, it usually goes unmentioned, and the writer is often not sure what was changed or why.
This article covers the specific patterns that cause review comments to be silently rewritten, and how to write feedback that travels unchanged.
What Gets Rewritten and Why
The patterns that trigger an editor's pen are not grammatical errors. They are register mismatches — places where the tone is either too formal, too hedged, or phrased in a way that would not occur to a native speaker. The editor fixes them not because they are wrong but because they "sound off."
Common triggers:
- Over-formal vocabulary when simple vocabulary would do.
- Excessive hedging before a clear recommendation.
- Passive constructions where active voice is natural.
- Sentence structures that are grammatically correct but syntactically unusual.
- Politeness phrases that are appropriate in one English culture but odd in another.
The Vocabulary Register Problem
Review comments and inline feedback should be in the same register as the document you are reviewing — generally professional but direct. Many writers overshoot the register into academic or formal bureaucratic language.
Before: "It is suggested that consideration be given to whether this section adequately addresses the subject matter in sufficient detail for the intended audience."
After: "This section could be more detailed — the audience may not have the background to follow the argument."
The second version says the same thing in 17 words instead of 31, and says it more specifically.
Hedging Before the Actual Comment
When writing a review comment, you have read the document carefully and formed a view. You do not need to apologise for having a view.
Before: "This is just a thought and I may be wrong, but I was wondering whether perhaps the conclusion could be strengthened."
After: "The conclusion could be stronger — it currently restates the findings without drawing a clear recommendation."
State the comment. If you are genuinely uncertain, say so briefly: "Not sure about this, but..." is sufficient.
The "Not Sure If This Is Helpful" Opening
A specific pattern that appears frequently in review feedback from writers with Asian professional backgrounds:
"Not sure if this is helpful, but..."
"This might not be relevant, but..."
"You may already have thought of this, but..."
These pre-apologies are intended as politeness. They produce the opposite effect: they signal that you are not confident your feedback adds value, and invite the reader to confirm that belief. If you are not sure the feedback is helpful, do not include it. If you think it is helpful, include it without the disclaimer.
Specificity Over Length
Vague feedback is useless to the author and often gets cut entirely in a review cycle.
Before: "I think the argument could be clearer."
After: "The transition between paragraphs 3 and 4 is confusing — the reader expects the next argument to follow from the client data, but the paragraph jumps to the cost analysis. A linking sentence would help."
Specific feedback travels. Vague feedback gets softened into nothing by an editor who is not sure what you meant.
Direct vs Softer Suggestions
Calibrate your directness to the relationship and the nature of the comment.
Direct (appropriate for close colleagues, clear errors, factual issues): "This figure is wrong — it should be $2.4M, not $2.1M."
Softer (appropriate for stylistic suggestions, senior colleagues, uncertain points): "Worth considering whether 'partnership' is the right framing here — the client may read it as a more formal commitment than we've made."
The key is that even the softer version is specific and forward-looking. It does not apologise for existing.
Comments vs Questions
Use questions when you want the author to reconsider something rather than simply correct it. Questions invite reflection without assigning blame.
"Is this the right metric to use here, given the Q2 comparison?"
"Would the client have the context to follow this reference?"
Questions also work well when you have noticed something that might be intentional — you are checking, not flagging an error.
Avoiding Cultural Friction in International Reviews
If you are reviewing a document that will go to an audience in a different country from your own, the calibration of your review comments matters. An Australian reviewer commenting on a US-targeted document should not flag American spellings as errors. A UK-targeted document should use "Kind regards" not "Best."
More subtly: review comments should not impose your home culture's directness norms on a document calibrated for a different audience. "This is too indirect for our Australian client" is a useful comment. "This is too indirect" — without the regional context — imposes a preference.
How Local Tone Handles This
When you paste review comments into Local Tone, the analysis identifies over-hedged openings, vague formulations, and register mismatches. The rewrite produces comments that are direct, specific, and appropriately calibrated for professional peer review. The notes explain the specific change and why it reduces the likelihood of silent rephrasing.
For related reading, see one-pagers that don't read as translated and writing critical feedback in English without sounding cold.
Quick Reference: Review Feedback Language
| Original phrasing | How a native reader interprets it | Improved version |
|---|---|---|
| "This is just a thought and I may be wrong, but perhaps the introduction could be slightly reconsidered?" | The reviewer is not confident. The feedback can be safely ignored. | "The introduction buries the key message. Lead with the recommendation, then provide context." |
| "It is suggested that consideration be given to whether this section adequately addresses the subject matter." | Over-formal, passive, and imprecise. The author doesn't know what to fix. | "This section needs more detail — the audience won't have the background to follow the argument without it." |
| "Not sure if this is helpful, but the conclusion feels a little weak to me." | Self-undermining. Invites the author to agree the feedback isn't useful. | "The conclusion doesn't land — it restates the findings but doesn't tell the reader what to do next." |
| "I think the data on page 3 might possibly need to be double-checked." | The reviewer is hedging on a factual issue. Creates ambiguity where there should be a clear flag. | "The revenue figure on page 3 doesn't match the source document — please verify." |
| "You may already have thought of this, but the tone in section 2 feels a bit formal for this audience." | The reviewer assumes their own observation is redundant before making it. | "Section 2 is too formal for this audience. The executive summary uses casual language throughout; section 2 should match." |
| "I would perhaps humbly suggest that the timeline on page 5 could perhaps be revisited." | Stacked hedges obscure the point. The word "perhaps" appears twice. | "The timeline on page 5 looks optimistic given the dependencies listed on page 3. Worth a second look." |
In Practice
Priya had been a senior analyst at a Melbourne consulting firm for two years when she noticed the pattern. Every time she contributed review comments to a client deliverable, at least a third of them were rewritten or removed before the document went out. Her manager — a native English speaker who had been at the firm for a decade — would do a final pass that "tidied up the comments." Priya's ideas were never challenged. Only the phrasing.
When she compared her original comments to the edited versions, a pattern emerged: her comments almost always opened with a qualifier ("I'm not sure if this is the right call, but..."), used passive constructions ("it could be considered whether..."), and ended without stating what specifically needed to change. The edited versions removed the openers, switched to active voice, and added a concrete action ("revise the chart to show year-on-year comparison rather than absolute figures").
Priya started writing her first draft of each comment, then doing a single edit pass with one rule: every comment must name the specific problem and say what should change. Within a month, her comments were going out unchanged. Her manager mentioned, in passing, that her written work had "really sharpened up." The thinking had been the same all along.
How to Self-Check Before You Send
- Read each comment and ask: does it name the specific location in the document (page number, section heading, paragraph)?
- Does each comment state what the problem is — not just that something could be improved, but why it is a problem for the reader?
- Does each comment say what should change — a concrete action, not just an invitation to reconsider?
- Remove any opening that begins with "I'm not sure," "this might not be relevant," "you may already have thought of this," or similar. Start with the observation.
- Check for passive constructions: "it is suggested that" and "consideration should be given to" almost always obscure who is supposed to do what. Rewrite in active voice.
- If a comment contains the word "perhaps" or "maybe" more than once, it is over-hedged. Keep one qualifier if the point is genuinely uncertain; remove it entirely if you are confident.
Frequently Asked Questions
Is there a risk that direct feedback will come across as harsh or critical in a way that damages the relationship?
The risk is real but smaller than most non-native writers assume. Direct feedback in a professional review context is expected and respected. What feels blunt to a writer from a more deferential professional culture often feels clear and helpful to the recipient. The hedge — "this might just be me, but..." — does not make the criticism softer; it makes the reviewer seem less sure. If you are genuinely uncertain about a point, one qualifier is fine. The problem is using hedging language not to signal uncertainty but to soften every comment regardless of your confidence level. When you do that, readers learn to discount your hedges and read past them anyway — so you lose the politeness signal and the clarity at the same time.
How specific does a review comment need to be to avoid being rewritten?
Specific enough that the author knows exactly what to fix without having to ask a follow-up question. "This section is unclear" is not specific enough. "The third paragraph of section 2 introduces three concepts in two sentences — the argument is easier to follow if each concept gets its own paragraph" is specific enough. A useful test: if you removed your name from the comment and showed it to someone unfamiliar with the document, would they be able to identify exactly what to change? If yes, it is specific enough. If they would need to ask "which part?" or "what kind of change?", it is not.
I write review comments in a shared Google Doc where my name is attached. Does the directness advice still apply?
Yes. In most Western professional contexts, direct named feedback in a shared document is standard practice. Your name being visible is an argument for being more specific and substantive, not less direct. Vague or heavily hedged comments can be harder to act on in a shared document because there is no private conversation to clarify them — the author either has to ask you publicly or guess at your meaning. A comment that says "this paragraph could be clearer" forces an awkward follow-up. A comment that says "the paragraph on page 4 mixes two arguments — split them into separate paragraphs with a clear link sentence" can be acted on immediately.