Immersive Translate Bilingual Display Broken? Fix Contrast Mode and Style Conflicts

When Immersive Translate bilingual display looks broken, confirm the engine still returns text: switch to translation-only or original-only. If either mode reads cleanly, the fault is the bilingual layer fighting page styles—not a dead install. Then try in order: change contrast/display mode, disable site user CSS or beautifier extensions, reset spacing and fonts to defaults, and compare on a short static English page. Overlap, drift, and covering text are usually CSS vs injected nodes; gray icons or silence everywhere belong on the not-working track.

People searching for Immersive Translate bilingual display or messy dual-language layout usually already get translations—they just see stacked lines, crushed paragraphs, or text floating into a sidebar. That is a different layer from “click Translate, nothing happens,” which belongs in the not-working checklist. Unclear package lineage starts at the download page. Inputs mistranslated or form help stuck belongs in the form input skip article. This post stays on display modes, style conflicts, and when to divert to lag or selection tracks.

Layout glitches vs not working

Layout-glitch signals: the job finishes, translations appear beside or under the original, but spacing collapses, glyphs overlap, blocks shift, or dark pages hide the new text.

Not-working signals: gray icon, no response, silence on every host, options will not open—load/conflict/permission territory in the not-working checklist.

Compare: clean profile, Immersive Translate only, one short static English page—translation-only first, then bilingual. Clean on the short page and messy only on one blog → style conflict. No text even on the short page → not-working first; stop tweaking line-height.

Bilingual / translation / original modes

Display mode decides how many nodes land and how much layout shifts. When debugging, switch modes before chasing font themes:

1. Translation-only: is the body readable alone without overlap? Yes → engine and inject work; the mess is the dual stack.
2. Original-only: does the page return to the site’s native layout? Yes → extension styles dominate; still messy → the site or another extension is rewriting the DOM.
3. Back to bilingual: try “translation below / beside” style options if present—pick the one that fights that host’s float/grid less.
4. Save per-site habits: some hosts stay translation-only; reading sites stay bilingual—cheaper than one global rigid preset.

A trap I hit: docs sites with tight line-height crushed two lines into one block; “translation after paragraph + a bit more spacing” or temporary translation-only beat endless global font tweaks.

Site CSS vs extension styles

The bilingual layer inserts nodes into paragraphs. Absolute positioning, fixed-height boxes, or hard rules on `p span` will squash or fling those nodes.

• User styles / Stylus / built-in reader themes → disable, then translate again.
• Ad blockers or “reader mode” extensions rewriting the DOM → retest with Immersive Translate alone.
• After changes, hard refresh (or close the tab); old pages may still carry the previous inject classes.

Core bilingual triggers also sit in the webpage translation guide—confirm manual trigger works before polishing display styles.

Line-height overlap and covering text

Most “broken” views are spacing or stacking order:

• Original and translation too tight → raise bilingual spacing / line-height in extension settings (labels vary by version).
• Translation color near the background → pick a higher-contrast theme, or use translation-only to verify content.
• Translation layer buried under site modals → close popovers/sidebars, then recheck the bilingual region.

Long threads and lazy-loaded comments insert more nodes as you scroll, so the page “gets messier.” Collapse comments before translating; if the fan also spins, treat scope separately in the high-CPU and lag article.

Dark theme, zoom, and font overrides

Forced dark mode, system font substitution, and zoom away from 100% amplify bilingual drift:

• Site or extension forces dark while translations stay light → use a dark-friendly palette in the extension, or temporarily disable forced dark.
• 125%/150% zoom makes baseline misalignment louder → verify at 100%, then decide on spacing.
• Custom fonts stuffing CJK and Latin into one line-height formula → reset to default fonts for the A/B test.

Quick A/B: same short page, default theme + 100% zoom + bilingual; then enable dark or custom fonts alone. Only the latter breaks → stay on theme/fonts; skip reinstall.

Vs lag or selection-popup faults

Avoid reinstall loops:

• Text appears but overlaps, drifts, or covers → this article: change mode, kill conflicting CSS, tune spacing and theme.
• Gray icon / silence everywhere → not-working checklist.
• Text appears but the machine cooks → high CPU & lag.
• Full-page bilingual OK, selection popup missing → selection popup fixes.
• Inputs/placeholders mistranslated, or form help over-skipped → form input skip checks.
• Unclear package source → verify on the download page, then retest.

Once stable, note which hosts stay bilingual and which prefer translation-only. Cheaper than resetting the extension every time lines stack.

FAQ

Broken bilingual = dead extension?

Usually no. Confirm text in translation-only, then check site CSS and spacing. Total silence → not-working checklist.

Only one blog looks messy?

Likely that host’s CSS or a beautifier. Private window, single extension; if still messy, tune mode and line-height.

Same as the selection popup?

No. Layout mess stays here; selection-only failure uses the selection guide; both dead → not-working.

Will style tweaks spike CPU?

Rarely. High usage → scope and tabs in the lag article; layout glitches → change display mode first.

Translated inputs = bilingual display bug?

No. Field mistranslate/skip uses the form-input article; overlapping paragraphs stay here.