Why Keeping the Original Changes Page Translation
FluentRead’s page translator is designed for a live webpage, not a static document waiting in a queue. This chapter focuses on the decisions that make bilingual reading usable: what gets translated near the reader, what remains untouched, how the original can be restored, and how the extension prevents a late result from being attached to the wrong page state. The practical payoff is a better prediction of whether an apparent failure is a provider problem, a recognition choice, or a deliberate boundary.
Translation follows attention, not just document order
A full-page translator has an obvious but costly option: inspect everything, send everything, wait, and then display the result. FluentRead normally takes a different starting point. It translates near the reader’s current position, while settings can expand the initial range or request whole-page processing. The difference is not merely a visual preference. It changes when work begins, how much text is sent at once, and what the reader can do while the rest of the page remains untouched.
Consider a long article. The reader may need the opening paragraphs immediately, but not the comments or footer. A reading-position workflow can produce help where attention is already directed. If the lower half has not changed, there is no reason to treat its untranslated state as proof that the extension is idle. Scrolling supplies a new reason to discover and process candidates. Whole-page mode is available when the reader wants a more complete result, but it trades the gradual experience for more upfront work.
This is also why “translate the page” should not be imagined as one request with one answer. The extension first has to decide which pieces are eligible, which are too short to justify a request, which belong to a protected region, and which can be safely displayed in the current mode. A paragraph that enters the reading area later may be a new candidate even if the page itself has not navigated. A heading, a link, a button, and a form value can all contain readable characters while having different consequences when their text changes. The reading-position policy is therefore a way of allocating attention and risk, not simply a throttle placed in front of a provider.
For the reader, this produces a useful diagnostic habit. If the first visible article paragraphs translate but a sidebar does not, the likely issue is scope. If a long page appears to stop at the fold and continues after scrolling, that is progressive processing. If a button remains in its original language while the paragraph below it changes, that may be an intentional control boundary. These observations are more informative than the broad conclusion that “the translator is inconsistent.” They identify which part of the page model is being applied.
The page is not treated as a uniform field of text. FluentRead can keep sidebars, headers, and footers outside the normal scope, skip very short fragments, and recognize a wider set of nodes when menus or navigation are missing. Those controls reflect a basic tension. A broader recognition scope can recover useful interface text, but it also increases the chance of translating labels the reader wanted to remain original. A narrower scope reduces noise and requests, but can miss content added by an unusual layout. The right setting depends on what the reader is trying to read, not on a universal definition of “the page.”
Bilingual placement makes another distinction visible. Prose, headings, and disclosure sections can keep the original and translation together because comparison is part of their function. Interface controls have a different constraint: their size and behavior are determined by the site. A translated button that is stacked under its original label can make a toolbar taller, wrap a row, or obscure the action. FluentRead therefore replaces the visible text of buttons, role-based controls, button-like links, and similar actions instead of adding a second line. When the original is restored, those labels return.
That replacement rule is deliberately incomplete. Submitted controls that carry a form name remain untouched, as do the contents of text fields. Translating those values could make a site receive an action it does not recognize or could rewrite text the reader is entering. The extension is therefore not maximizing the number of translated nodes. It is choosing where a translation can be added without changing the site’s contract with the reader.
That distinction becomes visible on a page with a search box or a checkout form. Translating the explanatory label may help the reader, but rewriting the value they entered could change the meaning of the next action. Similarly, adding a second line to a compact toolbar can push a site’s own controls out of alignment. A bilingual surface is successful only if the reader can still tell which text is content to compare and which text is an action the site expects to remain structurally stable.
There is a second reason to keep the original close: translation is not equally reliable for every kind of sentence. Short names, technical terms, and fragments can be ambiguous without their neighboring text. A reader who sees the original and the result together can notice when a proper noun has been normalized oddly or when a sentence’s certainty has changed. The extension’s display choices cannot guarantee that the provider made the right linguistic decision, but they can make the decision inspectable. That is a different and more defensible goal than presenting a fluent result as unquestionable.
The sequence is important because translation is asynchronous. The provider may answer after the reader has scrolled, expanded a disclosure, navigated within a single-page application, or restored the original. A result that was valid when requested can become wrong before it arrives.
A translation is committed only if the page still belongs to the request
The most visible interruption is a dialog. If an announcement or modal blocks reading, FluentRead handles the active dialog first and can pause unfinished page work until the reader closes it. Existing translations are not simply discarded. The work can continue from the new page state. A notice that does not block reading does not receive the same treatment, because pausing the whole process would add interruption without protecting interaction.
Scrolling creates a softer transition. New content may enter the viewport, or a page may add comments and navigation after the first pass. FluentRead’s ordinary recognition may not include every node. The user guide points to a broader recognition setting for menus and navigation, and to image or area translation when the visible text is drawn inside a picture. A site-specific rule can also describe the reading area and what should stay original, but the rule is not a substitute for understanding the page: an incorrect rule can translate too much or too little and must be checked after saving.
The harder problem is a late response. Suppose the reader starts translating a paragraph, then changes the page before the service answers. A single-page application may replace the article without a full reload; a disclosure may insert new text above the candidate; another tool may add its own translation wrapper. In each case, the visible location can remain familiar while the ownership of the source has changed.
A naive implementation could locate a similar text node and insert the result, even though the node now belongs to a different owner or contains new original text. FluentRead’s architecture describes several checks that prevent that shortcut. The request retains an ownership identity and a generation, and the committing side checks candidate eligibility and the current source text. The fact that a text object has the same shape, or that a whole paragraph still looks similar, is not enough to prove that the response belongs there.
This is a form of source protection. The result may be linguistically valid and still be a wrong answer if it is attached to the wrong source. The same logic applies when another translator operates on the page. FluentRead treats a known external translation boundary as something to recognize, not as an invitation to overwrite the other extension’s work. It should release its own translation when the external boundary takes over, and can rediscover the source if that boundary later disappears. Coexistence is therefore part of ownership, not an afterthought added to the provider layer.
Restoration completes the lifecycle. It is tempting to describe “restore original” as an undo button that merely removes translated text. In a dynamic page, it also resets the conditions for a new interpretation. If the reader changes language, service, recognition scope, or display mode, the old layer can no longer be treated as neutral background. Restoring first clears the previous output and gives the next discovery pass a known source state. This is why the installation guide recommends restoring before trying a different language or service.
The distinction between source and result is especially important for controls and lightweight display containers. The extension must preserve enough original information to put a button label or a translated slot back, but it must not remove ordinary site text, code, protected terms, or another translator’s content while cleaning up its own artifacts. A stable restore operation is therefore evidence that the extension knows which parts of the page it owns.
There are limits to this model. Unusual websites may hide their content behind structures that ordinary recognition does not identify. It helps to separate three different questions when diagnosing one. First, did the extension recognize the intended source? Second, did the selected service accept and return a result for that source? Third, was the result still allowed to commit when it came back? A “no” at the first stage calls for a reading-area or recognition adjustment; a “no” at the second points toward connection, quota, language, or provider behavior; a “no” at the third protects the page from a stale write. The visible symptom may be the same—a missing translation—but the safe remedy is not.
A custom site rule can improve the first stage, especially when a site consistently omits its article body or includes metadata the reader wants left alone. It also creates a new responsibility: the rule describes structure, not meaning. A selector that happens to match one page can overreach on another, and a rule that was correct before a site redesign can become too broad. FluentRead’s guide therefore treats custom rules as something to duplicate, test after restoring and retranslating, and disable or roll back if later content is wrong. This is a small but important example of the product’s broader stance: adaptation is useful when it is explicit and reversible.
The remaining failure cases are straightforward but important: a custom rule can be wrong, a provider can be busy or unavailable, and another extension can change the DOM in ways that require a fresh discovery pass. The architecture documents a correctness strategy, not a guarantee that every website will satisfy it. When whole-page translation fails while a single paragraph works, the useful response is to narrow the problem: check recognition, try a smaller unit, inspect the service connection, and determine whether another translator is active.
Page translation therefore has two outputs, not one. The first is the visible bilingual surface. The second is a maintained relationship between that surface and the original page state. When that relationship is protected, the reader can compare, scroll, pause, restore, and retry without treating each attempt as irreversible. Once the page has brought a difficult expression into focus, the next question becomes narrower: what should happen when the reader selects one sentence and needs an explanation rather than another layer of page text?