Localized Widget Chrome, Cached at the Edge

The chat widget you embed on your site is a small script that ends up running on thousands of other people's pages, which makes every change to it a little riskier than a normal deploy. That's exactly why the widget's interface text — button labels, status messages, the small bits of chrome around the actual conversation — now comes from its own dedicated, cacheable endpoint instead of being baked into the script itself.

What changed

Widget localization now lives behind a lookup keyed by locale, served from the edge and cached there, separate from the widget's core code. Practically, that means the set of languages a widget can display, and the exact wording used in each one, can change without anyone rebuilding or redeploying the embed script that's already live on your customers' sites. We also shipped automatic locale detection alongside this, so a visitor generally sees the widget in their own language without your team configuring anything per-visitor.

Why we built it this way

A widget script embedded across many external sites is not something you want to touch often — every redeploy is a chance to break something on a page you don't control and can't easily test. Splitting the translatable strings out into their own cached, edge-served resource means the highest-friction part of localization — adding a language, fixing a mistranslation, adjusting tone — no longer requires touching the part of the system with the widest blast radius.

What this means for you

Nothing changes about how you install or configure the widget today. The practical benefit is behind the scenes: language coverage and wording fixes can now ship faster and with less risk than before, since they're a content update rather than a code one.