Why generic translation apps struggle in medical and legal conversations

General translation apps are genuinely good at what they were built for: asking directions, reading a menu, buying a train ticket. The trouble starts when the same design is carried into a consulting room — because the design goals of a travel translator and a professional interpreter are close to opposites. Travel translation optimises for speed, price and working offline. Professional interpreting optimises for one thing: not being wrong. Three specific design choices explain most of the gap.

Failure one: the machine decides when your sentence ends

Conversation modes in general apps use voice activity detection (VAD): when you stop making sound for around a second, the app decides you've finished and sends what it heard for translation. That's fine for "where is the station". It falls apart in exactly the conversations that matter, because people pause when precision matters — recalling whether the pain started before or after the new medication, checking a date, choosing a word carefully in a legal matter.

The VAD hears the pause, cuts the sentence, and the engine translates half a thought with full confidence. The second half then arrives as a new fragment with no connection to the first. Both halves come out fluent; the meaning is quietly different. Worse, in a noisy waiting room the VAD does the opposite too — stitching a tannoy announcement or the conversation at the next chair into your sentence.

The solution is long-established and direct: push-to-talk. The speaker holds a button, talks — with as many pauses as thinking requires — and releases when the sentence is actually done. The boundary of every utterance is a human decision, and only the seconds the button is held are ever submitted, which is also why background noise never reaches the engine as speech.

Failure two: a model small enough to fit in a phone

Offline translation is a real feature with a real cost. To run on a handset, a model is compressed to a small fraction of the size of the engines that set translation benchmarks — and the ability that gets cut is precisely the long tail: specialist terminology, long clause-heavy sentences, and register. A pocket model does fine on frequent phrases and starts guessing on "paroxysmal atrial fibrillation" or the difference between a covenant and a condition in a lease.

Guessing is the dangerous failure mode, because the output stays fluent. Nothing looks wrong. In a medical consultation, the difference between "every twelve hours" and "twice a day, any time" is precisely the information that matters; in a legal one, a paraphrase that a professional would flag instantly passes through unmarked.

For professional settings the right trade is the opposite one: send every sentence to the strongest available cloud model, accept that this needs a connection, and get in return an engine that has actually seen the terminology, holds long sentences intact, and keeps the register of the room.

Failure three: every sentence translated as if the conversation just started

Most translation apps are stateless: each utterance goes to the engine alone, translated, forgotten. But a consultation is not a sequence of unrelated sentences. Statelessness produces three characteristic errors:

• Terminology drift. The same condition rendered three different ways in one session — the reader can't tell whether it's one problem or three.
• Broken references. "It got worse after that" — after what? With no memory of the previous turns, pronouns and back-references become unreliable, especially between languages that drop subjects (Chinese, Japanese) and languages that require them.
• No use of what's known. The patient's history, the case background, the fact that this is a lease negotiation and not a chat — all invisible to the engine, so it can't disambiguate the way any human interpreter naturally would.

The solution is context, applied systematically: tell the engine the scenario (medical rules are not legal rules — dosage must be exact; legal language must never be paraphrased), give it the background up front, let it follow the whole conversation, and pin terminology so a term rendered one way in minute two is identical in minute twenty.

What to look for instead

If a conversation is one where an error costs something, check the tool against five requirements:

• Speaker-controlled turns — push-to-talk, not auto-segmentation;
• Top-tier cloud models — not an on-device engine;
• Scenario and background — a way to tell it what kind of conversation this is;
• Terminology memory — consistent renderings across the session;
• A bilingual record — transcript and summary you can verify afterwards.

This is the checklist AI Interpreter was built against — hold-to-speak turns, every sentence translated by top-tier cloud models, nine scenario presets with their own terminology rules, a dictated background for professional consultations, and a bilingual transcript, summary and glossary at the end. The checklist itself, however, stands independently: whatever tool is used for a conversation that matters, those five properties are the difference between a travel tool and a professional interpreting tool.