Banner translations

How does the embed pick a language?

The embed reads navigator.language, which is the language the visitor's browser reports, and looks for a match in two passes:

• It tries the exact tag first. A browser reporting pt-BR gets your pt-BR translation if you added one.
• Next it tries the primary subtag. If there's no pt-BR overlay, the embed looks for pt.
• If nothing matches, the banner renders your base copy.

This order means regional copy gets used when you have it, and a generic pt translation still catches every regional variant you haven't written. Browser language is also a preference visitors set themselves, so matching it means you're asking them in a language they chose.

Adding a translation

Open the banner customizer (Banners → Consent banner → Edit) and use the Editing picker in its top bar. There's 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're picking from names your visitors would recognize instead of anglicized versions. If the language you need isn't a preset, add any valid BCP 47 tag.

A translation covers more than the buttons. You can translate category names and descriptions per language, so "Marketing" and the sentence explaining what marketing cookies do can both change with the visitor's language. If you translate only the buttons, visitors can click them but may not be able to read what they're choosing.

Partial translations

Translations are overlays, applied field by field, and any field you leave empty falls back to the base copy for that field. With that fallback in place, a missing string can't render a button with no label on it.

This also means you can work in stages. Translate the high-visibility fields first (the title, the accept and reject buttons), publish, and finish the category descriptions later. The banner keeps working at every stage, but until you finish, visitors still see base copy in the fields you haven't translated.

Does the banner handle right-to-left scripts and screen readers?

Yes. Arabic, Hebrew, Farsi and Urdu render right-to-left automatically. There's no direction toggle to set, because the language decides it.

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. Without it, screen-reader users might not be able to follow your translation at all.

Check it in the preview

The preview follows the Editing picker, showing whichever language you're editing. It runs the same overlay the embed runs, with the same matching and the same field-by-field fallback. When you switch to a language, you see 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 fields you forgot. Step through each language before you publish and look for copy that's still in the base language, because those are your empty fields.

Recording which language was shown

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

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." Because the language is stored on the event itself, you can give the second answer and back it up.