Chrome's translator re-scans what becomes visible rather than watching your document through a MutationObserver [16]. That one design choice decides what your instrumentation can see. The dev.to writeup behind these figures records about a month of measurement across Chrome, Edge, Firefox, Yandex and Google's translate_a/element.js widget, with the published numbers taken from a raw recording on Windows against Chrome 151, dated 2026-09-02 [3]. The author had written down, and had a probe proving, that Chrome never repairs a text node you restore. The probe sat below the fold. With the element in view, Chrome repaired the restored node in 210ms, and the shipped claim was wrong for two days [17]. A probe below the fold measures a translator that is not looking.
Whether you get a stack trace or a stuck screen is decided by markup most reviewers treat as cosmetic. A bare `{visible && 'There are 4 lights!'}` is cleared by React with `textContent`, and nothing throws; put a `<span>` next to it and the string becomes a real text node that React removes by reference, which is the throw [8]. Interpolation with literal text on both sides, `<p>There are {count} lights!</p>`, compiles to three separate text nodes, and that is the shape that freezes instead of crashing [9].
Treat the timings as claims about one app on one machine. The update series was five replicates of four updates sampled every 50ms [19], so a 210ms repair resolves into roughly four samples [1]. That is enough to argue hundreds of milliseconds, not enough to argue 210 against 180. For the numbers to transfer, your readers need to be on Chrome desktop with the node in view, and your update cadence needs to sit near the once-a-second counter used in the Edge and Firefox probes, which left the node connected and let writes land, reaching 6 in both browsers [12]. At that cadence a 210ms repair window leaves about a fifth of each second showing untranslated text [2], which is why a price that changes once is a flash nobody reports while a counter pays it every tick [20].
The second recovery option, writing your new value into the wrapper the translator already built [18], is where locale walks in. Splicing a fresh digit into an already-translated Dutch sentence works. In Russian it breaks agreement: `Intl.PluralRules('ru')` puts 4 in `few` and 7 in `many`, the noun follows the category, and an early build shipped exactly that error [21]. The merge now refuses when the plural category, the digit count or the sentence shape changes, or when the locale is unknown, and on refusal the reader gets the right number in the source language [22]. Dutch and German report `other` at every count, so a team developing against those locales never sees a refusal happen [23].
Two pieces of this are good engineering worth copying. Yandex wraps translated text in `<ya-tr-span>` and keeps your source string in a `data-value` attribute [6], which is a recovery path handed to you; Google's nested `<font dir="auto" style="vertical-align: inherit;">` pair keeps nothing [5]. And the fingerprint that actually works is the inline style, not the computed one: `getComputedStyle(wrapper).verticalAlign` returns `baseline` because the cascade resolved it, while `wrapper.style.verticalAlign` still reads `inherit` [14].
