We added an optional language switch to customer sites. It is Google’s Translate widget behind one site setting. The hard part was deciding where it was allowed to run.
What the widget does to a page
The feature was small on paper. A site owner turns on a “Visitor language selector” and picks which languages to offer. A visitor gets a small dropdown that swaps the page into their language on the fly. The widget rewrites the rendered text in place, so it translates whatever it can see, including team names and event descriptions the owner typed themselves.
That is the point of the feature, and it is also the risk. The widget has no idea which text is public content and which control belongs to the owner. So the boundary had to be ours.
Where the boundary went
Three decisions did most of the work:
The setting is off by default and lives under Advanced Settings, International. Nothing changes on a site until its owner flips it.
The selector renders on visitor pages only. Admin pages run under a different zone in the code, and the check returns early for anything that is not the visitor zone, so the owner’s own dashboard never loads the widget.
The list of languages is a fixed set of 22 codes. The save handler filters against it on write, and the page filters against it again at render time, because the list ends up inside an inline script and a stored value is not something to trust there.
Saving any of those settings also clears the page cache in the same request, so a toggle takes effect on the next visitor view instead of racing a cached page.
The layout guess that did not survive the demo
The first version pinned the dropdown to the top right with absolute positioning. In the demo it came out as a full-width bar under the nav. The container around it had no positioned ancestor, so the browser measured against the whole page. Making that container relative would have touched a template used on every visitor page, ads included. So the selector stayed a normal-flow row under the nav, right-aligned and small, the lowest-risk spot in the template for a control that has to be on every page.
What happened before it shipped
The design went through Manus and Codex as two independent reviewers, then a separate verification pass that checked the finished behavior against the design instead of against the code. The widget was then run end to end on a look-alike copy of a real site, not a real customer’s. The hotfix landed on a review branch with dev notes and a summary on the ticket, and stopped there for a human to sign off before anything reached production.
AI Skills
Use this lesson with the AI assistant you already use
A visitor-facing translate toggle sat one careless selector away from also rewriting the controls the site's own owner uses to run the page underneath it.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: An Opt-In Translation Layer Has to Be Scoped Narrower Than "the Whole Page"
SOURCE: dxdev.com/blog/2026-09-05_translate-widget-scope-boundary
WHAT HAPPENED: A platform added an optional, visitor-facing language selector to customer sites: a site-level setting that drops in a third-party machine-translation widget so a visitor can flip the page into another language, including content the site's owner wrote themselves. Machine-translating owner-authored prose is a different risk than translating static system chrome, because a translation widget by default has no concept of "this element is a visitor label, that one is an owner's control." Before shipping, the design went through two independent reviews plus a separate verification pass, and the finished widget was proven end to end on a look-alike copy of a real site, not production, before the change went out as a hold pending sign-off.
THE RULE: Any feature that runs a generic transformation (translation, formatting, autolinking, anonymization) across a page needs an explicit scope boundary between "content the visitor sees and can safely have transformed" and "controls the operator uses to run the thing," and that boundary has to be proven on a non-production copy before it reaches a single real site, because the failure mode (the transform reaching an operator control) doesn't announce itself, it just quietly changes what a button says.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Any DOM-wide or page-wide transformation (translation, formatting, sanitization) that isn't explicitly scoped to a container marked "visitor content only."
2. Any new opt-in feature shipped to a live customer/tenant without first being proven end to end on a non-production look-alike copy.
3. Any review of a feature like this that had only one reviewer, or no independent verification pass separate from the person who built it.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.