Should live translation preserve uncertainty, or hide it?

I’m a multilingual software engineer, and I’m increasingly uneasy about how polished real-time speech translation sounds in remote meetings. Systems often remove fillers, repetitions, false starts, and self-corrections because fluent output scores better and arrives faster. That is fine for “um, can everyone see my screen?” It is not fine for an incident review.

“I think the rollback fixed it—uh, no, error rate is still climbing” cannot become “The rollback fixed it.” The hesitation and correction are part of the operational meaning. Code-switching and dialect markers can matter too: silently standardizing a command, product name, or deliberately chosen term may erase the reference that lets others diagnose the problem.

My position is to compress harmless disfluency, but expose meaningful uncertainty and self-repair, perhaps with subtle speech or transcript markers. Lower latency matters, but a fast, confident mistranslation is worse than a slightly delayed one. Should translated speech expose confidence or disfluency markers? Please bring concrete examples or counterarguments.

I agree for incident response, but I would not make every hesitation audible by default. In customer or executive meetings, constant translated “ums” will feel broken and may make a careful speaker sound incompetent. Give the listener a confidence layer or expandable transcript, not more latency in the audio path.

The dangerous part is not the filler; it is the system deciding which uncertainty is meaningful. A model that confidently labels a phrase as uncertain can still mislead. I’d preserve the raw audio and show revisions in the transcript, with the translated voice allowed to stay relatively smooth.

The rollback example is decisive because the speaker performs a self-correction, not merely a pause. Removing that changes the incident record. I’m less convinced dialect markers should always survive, though: some may be recognition noise rather than intentional signals. The interface needs to distinguish those cases.

Latency wins in ordinary conversation. If I wait two seconds after every clause, people will switch back to speaking over one another. My compromise: smooth audio, but emit a visible “translation revised” or “speaker uncertainty” marker when the system changes a technical claim.

There’s a social cost to preserving everything. Native speakers also use hesitation strategically, and translated disfluency could exaggerate doubt for listeners who already distrust an accent. Maybe the safest default is semantic preservation plus access to the original audio, rather than trying to encode every vocal cue in synthesized speech.