Chrome Translate Caused React Hydration Errors — Diagnosis and Mitigation

Quick summary: Chrome (Google) Translate may modify the DOM (text nodes, attributes, markup) when translating a page. Those modifications can cause React/Next.js server-rendered pages to fail hydration or throw runtime errors. This post documents how I diagnosed the issue on my site, what I tried, and the recommended mitigations.

The problem we saw

On the English site, when a user clicked Chrome's built-in "Translate to Chinese" UI, the page would immediately throw a client-side error and become unusable until refreshed. The error only occurred when using the browser's translation feature — normal browsing was fine.

Symptoms observed:

Page crashed after clicking Chrome Translate
Console showed hydration/DOM mismatch or runtime exceptions
Refreshing the page returned it to normal

These symptoms point to a DOM mutation performed by the browser extension/feature (Google Translate) that conflicts with React's assumptions about server-rendered markup.

Why this happens

React Server Components / SSR + hydration assume the DOM produced on the client matches the server-rendered HTML. When Chrome Translate injects extra elements, modifies text nodes, or changes attributes (for example setting html.lang to zh), the client-side React may detect mismatches or encounter unexpected node shapes, producing hydration warnings or runtime errors.

This is a known class of issues — see related React discussions like issues mentioning Google Translate and hydration mismatches.

How I reproduced and captured logs

I created a small headless repro using Puppeteer that:

loads the English page (/en)
simulates Translate by mutating text nodes and setting document.documentElement.lang = 'zh'
listens for console, pageerror, and error events and writes them to a log file

The script lives at scripts/repro-chrome-translate.js and writes tmp/translate-repro.log with captured messages. The initial logs showed the injection step and helped confirm client-side scripts threw errors after the mutation.

If you need to run it locally:

# Run dev server in one terminal
pnpm dev
 
# In another terminal (from repo root)
node scripts/repro-chrome-translate.js
# Result: tmp/translate-repro.log

Mitigations we tried (and why)

Disable browser auto-translate for English pages

Implemented at the root HTML by adding translate="no" on <html> and a meta tag <meta name="google" content="notranslate" />.
Effect: Prevents Chrome from automatically translating the page and therefore avoids the DOM mutations that cause the crash.
Status: Kept as the immediate fallback — simple and effective.

Add a dismissible site-level translation hint (UX)

Instead of silently blocking translation, we briefly experimented with showing a small banner that tells users the site supports its own translations and suggests using the site translator or switching locales.
The banner was dismissible and auto-hidden.
Status: Implemented, then reverted temporarily while we stabilized behavior (see below).

Add a client-side ErrorBoundary

We added a lightweight React ErrorBoundary to catch uncaught client errors and show a friendly fallback UI (Reload / Try again). This reduces the impact of a single exception from taking down the whole page.
Status: Implemented as a mitigation, later reverted along with the UX experiments. Error boundaries are still recommended for robustness.

Protect critical UI with a snapshot-and-restore approach

Implemented ProtectFromTranslate which snapshots key DOM (outerHTML of #__next children) and watches document.documentElement.lang for changes. If the browser sets lang to zh*, the component attempts to restore snapshot HTML for modified nodes.
This is an heuristic mitigation to recover from translation-induced DOM mutations.
Status: Implemented, tested locally, then reverted at the team's request because we preferred the simpler "disable translation" approach for now.

Final approach chosen (for now)

Keep translate="no" + <meta name="google" content="notranslate" /> in the root layout for English pages. This prevents the browser from auto-translating and avoids the immediate crash.
Keep the codebase free of Chinese in English content (no mixed languages in content/posts/en/).
Have an internal plan to reintroduce safer UX (site translator / dismissible hint / error boundary) later after more testing.

This approach favours stability and predictability: preventing the browser from mutating the DOM avoids the class of hydration issues entirely.

Code snippets

Root HTML (Next.js app/layout.tsx) — disabling translate:

<html lang="en" translate="no">
  <head>
    <meta name="google" content="notranslate" />
  </head>
  <body>...</body>
</html>

Lightweight ErrorBoundary (concept):

// components/error-boundary.tsx
'use client'
import React from 'react'
export class ErrorBoundary extends React.Component { /* show fallback UI */ }

Protect-from-translate idea (concept):

// components/protect-from-translate.tsx
// Snapshot outerHTML of critical nodes on mount
// Observe document.documentElement for lang attribute changes
// If lang becomes zh*, restore snapshots for modified nodes

Alternatives and trade-offs

Fully allowing browser translation: easier for users, but fragile for SSR/hydration. Requires more sophisticated defensive coding (MutationObservers, protected DOM regions, re-render triggers) and extensive testing.
Site-provided translator: best UX if you can provide high-quality site translations (via an LLM or translation API). This avoids relying on the browser, but introduces cost and complexity.
Granular translate="no" attributes: instead of globally blocking translation, you can apply translate="no" to specific components that must not be changed (headers, interactive widgets). This gives a fine-grained balance.

References

React issues discussing Google Translate & hydration mismatches (search in React's repo)
Community discussions on StackOverflow about Google Translate causing DOM/hydration problems

Takeaways

Browser translation can change the DOM in unexpected ways; for SSR React apps that rely on consistent server/client HTML, this can cause real failures.
Short-term fix: opt out of automatic browser translation for critical locales/pages.
Medium-term: add runtime protections (ErrorBoundary, selective translate="no", or guarded components) and consider providing a site-managed translation experience.

If you'd like, I can:

Reintroduce a minimal, safe ErrorBoundary only (no UX banner), or
Implement fine-grained translate="no" on specific selectors (header, hero), or
Rework ProtectFromTranslate to be less invasive (restore only text nodes instead of replacing outerHTML).

Tell me which follow-up you prefer and I'll implement it.

— Leon — January 31, 2026