Consent on multilingual client sites: the banner has to speak every language

Consent has to be informed to be valid, and consent cannot be informed in a language the visitor does not read. A multilingual site with an English-only consent banner is not mostly compliant; it is non-compliant everywhere the banner fails to communicate. Agencies that ship multilingual client sites need a consent setup where the banner, the preference center, and the policy all follow the visitor's locale, not the developer's.

The finding nobody sees coming

Multilingual sites usually get built locale by locale, and consent gets configured once, in the default language, on the homepage template. The Spanish and French versions inherit the banner without anyone checking what it says. Automated scanners test the default locale. The client's legal team reviews the default locale. Then a regulator in Quebec or Spain checks their own locale and finds a banner the local visitor cannot understand.

This is especially painful because the fix is not hard, which makes it look negligent. Translating banner copy is a few hours of work. The reason it gets skipped is ownership: the translation agency handles marketing copy, the consent vendor handles the banner config, and nobody's scope covers the intersection. Put it in the agency's scope explicitly, in the statement of work, and it stops falling through.

What has to be localized

Everything the visitor reads during the consent flow: the banner text, the accept and reject buttons, the preference center labels and descriptions, and the cookie policy or privacy policy link it points to. The policy itself needs full translation, not just the banner pointing at an English policy. A Spanish banner that links to an English policy fails the same test as the English banner did.

Also localize the consent categories' explanations. "Statistics" and "marketing" are abstract enough in English; in translation they need the same care as any UX copy. Vague or misleading category descriptions in any language undermine the "informed" requirement. Have a native speaker review the consent copy, not just run it through machine translation. Consent language is legal-adjacent copy, and precision matters.

The technical setup that actually works

The cleanest approach is one consent configuration per locale, keyed off the same category schema. The categories stay identical across languages so the backend logic does not fork; only the display strings change. Most consent platforms support locale-specific display text natively, and the ones that do not can be driven with a small mapping layer in front of the banner.

Key the locale off the visitor's actual browsing language, not their IP. A French speaker in Montreal and a French speaker in Paris need the French banner; geolocation guessing gets this wrong in both directions. Use the site's own locale routing, the same mechanism that serves the French page, to serve the French consent copy. When the site and the banner disagree about which language the visitor reads, the banner loses.

Testing across locales

Add the consent check to the localization QA pass, not the consent QA pass. Whoever reviews the Spanish pages for copy quality should also click through the consent flow in Spanish: banner, preferences, save, withdraw. Two minutes per locale, done by the person who actually reads the language. A separate consent test in English tells you nothing about the Spanish banner.

Also test the edge locales: the ones the client added last month, the ones served from a subdomain, the language variants of the checkout flow. Consent regressions cluster at the edges of the site, where the newest locale meets the oldest template. A quick script that loads each locale's homepage and screenshots the banner pays for itself the first time it catches a missing translation.