Banner translations

How the embed picks a language

The embed reads navigator.language — the language the visitor's browser reports. Matching runs in two passes:

• Exact tag first. A browser reporting pt-BR gets your pt-BR translation if you added one.
• Primary subtag next. No pt-BR overlay, and the embed looks for pt.
• No match at all, and the banner renders your base copy.

The order matters. Regional copy wins when you have it, and a generic pt translation still catches every regional variant you haven't written. Browser language is also a preference the visitor set themselves. Matching it means you ask people in a language they chose, not one you guessed.

Adding a translation

Open the banner customizer (Banners → Consent banner → Edit) and use the Editing picker in its top bar. There is no separate Languages tab: a language is a mode of the same editor, so the Content tab edits whichever language the picker names. + Add lists 22 preset languages, each labeled in its own script. You pick from what your visitors would recognize, not from anglicized names. If the language you need isn't a preset, add any valid BCP 47 tag.

A translation covers more than the buttons. Category names and descriptions are translatable per language, so "Marketing" and the sentence explaining what marketing cookies do can both change with the visitor's language. A banner where the buttons are translated but the explanations aren't is only half asking.

Partial translations never render a blank button

Translations are overlays, applied field by field. Any field you leave empty falls back to the base copy for that field. The reason is defensive: a missing string should never render a button with no label on it, and with field-level fallback it can't.

This also changes how you can work. Translate the high-visibility fields first (the title, the accept and reject buttons), publish, and finish the category descriptions later. The banner stays functional at every stage. Be honest with yourself about what that buys you, though: a half-translated banner is still half-translated. The fallback keeps it working; it doesn't finish the job.

Right-to-left scripts and screen readers

Arabic, Hebrew, Farsi and Urdu render right-to-left automatically. There is no direction toggle to set. The language decides.

The banner also carries the lang attribute for whatever language it rendered. Screen readers use that attribute to pick pronunciation rules, so Spanish copy is read with Spanish phonetics instead of being mangled through an English voice. A translation a screen-reader user can't parse would defeat the point of translating.

Check it in the preview

The preview follows the Editing picker — the language you are editing is the language on screen — and it runs the same overlay the embed runs: same matching, same field-by-field fallback. What you see when you switch to a language is exactly what a visitor reporting that tag gets, including which fields are falling back to base copy.

That makes the Editing picker the fastest way to find the fields you forgot. Step through each language before you publish and look for copy that's still in the base language. Those are your empty fields.

The evidence: which language was actually shown

Every consent event records the language the banner actually rendered, and the CSV export carries it in the language column.

The reason is contestability. Consent given to words a visitor couldn't read is open to challenge. If someone later argues they didn't understand what they agreed to, "the banner was available in their language" is a weaker answer than "the banner was shown in their language, and here is the record." With the language stored on the event itself, that second answer is the one you can give. It's provable, not assumed.