Why Generic AI Translation Silently Fails
The most dangerous translation error is not a wrong word. It is a wrong word the system reports as a successful translation. Generic chat-based AI translation is structurally prone to this. Quota errors come back as apologies in plain text. Safety blocks come back as polite refusals. A chunk that translates only half-way comes back as a chunk that looks translated.
What goes wrong
You ship a translation that contains, somewhere in the middle, a sentence in the source language because the model decided to stop. Or a chunk that says "I cannot help with that" in fluent prose. Or a billing failure rendered as an English apology, embedded in your target-language document.
Why generic AI translation fails here
The API call returned a 200. The response body contains text. Nothing in the transport layer says anything is wrong. Heuristic post-checks (for example, "is the output mostly in the target script") sound reasonable but misfire on bibliographies, code blocks, and citation-heavy chunks where source-language tokens are a feature of the content.
How TranslationAI solves it
Provider quota exhaustion is treated as fatal and surfaced immediately, not retried into silence. Each chunk is translated by an independent prompt over its own source segment, so damage from any single bad chunk is bounded to that chunk and recoverable by retry. When a provider returns an error the real reason is written to project state and rendered inline on the page, surviving refresh and navigation. The system does not run a script-ratio language gate; we tried one, it caught no confirmed bad translations and did reject legitimate citation-heavy chunks, so it was removed in favour of surfacing the real provider error.
Further reading: why a failure must be resumable, verification as a design pattern, three root causes of consistency drift.