The tool was right. That was the problem.
I had just added a changelog entry to sh0's marketing site and corrected a documentation page. Before pushing, I ran the responsive checker we keep for exactly this — a small script that drives headless Chrome, measures horizontal overflow at 390, 768 and 1280 pixels, and exits non-zero if any page scrolls sideways. It reported one failure:
[DÉBORDE] /fr/docs/databases/backups-restore @390px
→ overflow=130px · coupable=a.flex.items-center [right=520]Precise. Reproducible. Named the offending element (the tool speaks French; coupable is
"culprit"). Everything a good error message should be, and it invited exactly the wrong fix.
The five-minute repair I did not make
The obvious reading: some anchor in the page footer is too wide at phone width. Probably the previous/next navigation, where a longer French label refuses to wrap. Add min-w-0, add truncate, re-run, green, push. Five minutes.
Two things stopped me. The English version of the same page measured zero. And our own house rule, written after a previous incident, says to look at the captures rather than trust the number.
The capture was 520 pixels wide. The viewport was 390.
That is not a page with a wide element in it. That is a page with no stylesheet. Chrome had laid out raw HTML at its natural width, and the "overflow" the tool reported was the difference between an unstyled document and the viewport I had asked for. The measurement was accurate to the pixel. The thing it measured was not a layout defect — it was the shadow of one.
What was actually broken
SvelteKit emits asset links relative to the page's own depth. The English page lives at /docs/databases/backups-restore, three segments deep, so its stylesheet link is:
html<link href="../../_app/immutable/assets/0.B9O4bhzJ.css">From /docs/databases/, ../../ lands on the root. Correct.
That same prerendered file was being served at /fr/docs/databases/backups-restore — four segments deep. Now ../../ lands on /fr/, the browser requests /fr/_app/immutable/assets/0.B9O4bhzJ.css, gets a 404, and renders the document naked. Same for every script tag. The page was also, of course, in English: it was the English file.
Two curl calls confirmed it, and one of them is the whole story in a single line:
$ curl -s https://sh0.dev/fr/docs/databases/backups-restore | grep -o '<html lang="[a-z]*"'
<html lang="en"Why the French file did not exist
The site prerenders. Marketing pages get explicit entries in svelte.config.js — a hand-maintained array of 57 paths, expanded across four locales, because those pages sit behind hover dropdowns the prerender crawler cannot follow. Documentation pages were never added to that array. They were left to the crawler.
The crawler follows links that appear in rendered HTML. /fr/docs links eleven sub-pages. Following those, and what they in turn link, reaches twenty-five. The remaining twenty-three are reachable only through a sidebar the crawl never expands. So twenty-six French documentation pages were prerendered (the index plus the twenty-five reachable from it), and twenty-three were not. For those twenty-three, the locale-stripping reroute found the English prerendered path, decided it had a file to serve, and served it.
Twenty-three pages, four locales. I checked all 196 localized documentation URLs on production:
checked=196
mismatch=92Ninety-two URLs, live, serving unstyled English. Not a regression from my change — this had been shipping for as long as the docs had been translated.
The fix is two spread lines and the list they cover: a docsPages array of all forty-nine routes, built exactly the way the fifty-seven-entry pages array already was, expanded across the same four locales. Twenty-eight lines of configuration, of which twenty-six are the route names. The mechanism had existed all along. Nobody had extended it to the second directory.
Two false trails, and the test that costs thirty seconds
The 500. Locally, that same route returned a 500 with TypeError: fetch failed. Tempting to chase — it is loud, it is on the exact page under suspicion. It was an artifact of the preview server: adapter-node started without ORIGIN, and the self-fetch SvelteKit performs for a rerouted prerendered path has nowhere to go. Production never had it. Setting ORIGIN made it disappear.
"I broke this." The more expensive trail, because it leads to reverting good work. I had touched that page minutes earlier. The test that settles it took one command: run the same check against /fr/docs/databases/connection-strings, a page I had never opened. Identical signature — 130 pixels, same named culprit, same right=520. A defect that reproduces on a file you have not touched is a defect you revealed, not one you introduced. That distinction is worth thirty seconds every single time.
The part that generalises
This is the second time a measurement tool has quietly reported the wrong thing on a ZeroSuite site, and the two failures are the same shape inverted.
The first: an authenticated responsive run whose session expired mid-series. Every subsequent page rendered the public marketing home instead of the page under test. Zero pixels of overflow, sixteen renders, success. The captures were not blank — they were full, attractive and plausible. Nothing in the report distinguished them from a real pass. We fixed that by making the tool fail when an asserted selector is absent: having measured nothing must fail, not succeed.
The second is this one. A red number, correct in its arithmetic, pointing at an element that was innocent.
Both cases have the same root: a tool reports what it measured, and what it measured is not necessarily what you think you asked for. Green does not mean the thing you care about is fine. Red does not mean the thing it names is guilty. The number is a pointer into the artifact, and the artifact is where the answer lives.
Had I fixed the anchor, the checker would have gone green. The page would still have been unstyled, still in English, and ninety-two URLs would still be broken — now with a passing test standing over them.
What shipped
One array and two spread lines. All five locales now prerender all forty-nine documentation pages; French had twenty-six. Re-measured on production after deploy: 196 URLs checked, zero mismatches. The responsive suite passes locally at 390 and 768 pixels over seven routes in three languages, and again on production at 390 across four locales — and the captures, which I looked at, are 390 pixels wide.
The overflow is gone. It was never the bug.