A consent banner that was right on this site and wrong in the package

I found a bug in my own shared package while fixing a different site, and it turned out I’d already carried the same bug over here without noticing.

The short version: while adding Portuguese to vdaluz.com, I was extending the PrivacyExplainer component’s copy in @vdaluz/astro-opt-in-analytics, the package that renders the consent banner and privacy-page copy across all my Astro sites. Only default and es keys existed in the package before that. Adding pt made me go check every site pinned to it, and this one came up: it has a live /pt/privacy route and renders the same consent banner on every pt page via its layout, but was still pinned to v0.5.0.

Why nothing looked broken

This site’s own code was already correct. Its analytics config had pt copy defined for months, “Pode contar” for accept, “Não, obrigado” for decline. It was never used, because resolveLocalized() falls back to .default (English) whenever a locale key doesn’t exist in whatever’s passed to it - and the package, not this site’s config, is what decides which locale keys are valid.

So pt visitors were seeing an English consent prompt and an English privacy page. No error, no missing-string warning, nothing that looked wrong from inside this repo. Just the wrong language rendering silently, which is the same class of thing I keep finding at package boundaries.

The fix, and the two false readings during verification

The fix itself was one line: bump the tarball pin from v0.5.0 to v0.5.1, npm install, rebuild. The verification took longer than the fix, on purpose, because “silently wrong language” is exactly the kind of bug a clean build and a passing astro check won’t catch.

I grepped the built HTML for the actual Portuguese strings, then drove a real browser to the pt homepage and privacy page to see it myself. The first pass showed nothing, because my browser profile already had a consent decision saved in localStorage from testing this site weeks ago, so the banner was hidden by design. Clicking “Preferências de análise” in the footer reopened it, and there it was: “Posso contar sua visita?” with both buttons in Portuguese.

Then I hit the same trap again post-deploy. The first live request I made landed on a build that had started before my commit existed, so it was still serving the old English strings. I had to diff the deployment timestamp against the commit timestamp before trusting the “it’s live” check - which is a habit worth having, since a check environment lying to you is more common than a fix genuinely failing.

Lesson

This bug could only be found by looking at two projects at once. Nothing in this site’s own tests or checks would ever catch a missing locale key in an upstream package, because from this repo’s point of view the config was always correct. The bug lived entirely in the gap between what this site configured and what the package actually supported.

Cross-repo shared components are convenient right up until the day you have to remember they can drift out of sync with themselves.