Locales

The widget renders both its own interface chrome and your translated guide content in a single locale. You choose the language explicitly, or let the widget pick the visitor's preferred one — either way the installer reads the steps in plain language they understand.

You will learn

• The order Inboard uses to decide which locale to render.
• How to force a locale, and how to let the widget auto-detect.
• What happens when a string hasn't been translated yet (spoiler: it never renders blank).
• Why you don't manage translation files yourself.

How a locale is chosen

When the widget mounts it resolves a single locale in this order, stopping at the first match:

1. Explicit option — data-locale on the script tag, or locale passed to Inboard.init().
2. Visitor's browser locale — the language the installer's browser advertises, if Inboard ships translations for it.
3. Your project default — the default locale configured on the project in the dashboard.
4. English — the source locale, always available as the final fallback.

Locales are BCP 47 language tags — en, fr, de, es. Region subtags (en-GB, pt-BR) are accepted and matched down to the base language when a region-specific set isn't published.

Forcing a locale

Pin a language when you already know your installer's audience — for example a Spanish-only onboarding flow:

<script
  src="https://app.inboard.dev/widget/inboard-widget.js"
  data-embed-key="tpl_abc123"
  data-target="#inboard"
  data-locale="es"
  defer
></script>

Or set it dynamically — handy when your own app already knows the signed-in user's language:

Inboard.init({
  embedKey: "tpl_abc123",
  target: "#inboard",
  locale: user.preferredLanguage, // e.g. "fr"
});

Auto-detection

Leave locale unset and the widget reads the visitor's browser preference. If Inboard publishes that language it's used; otherwise the widget falls through to your project default, and finally to English. You never get a half-rendered guide because there is always a complete fallback.

Partial translations never break a guide

Translations are applied per field. English is the source locale, so an en render is served directly with no translation lookup. For any other locale, each translated string is overlaid onto the English source only when a non-empty translation exists for it — any string that hasn't been translated yet keeps its English source text.

The practical effect: a locale that's 80% translated renders 80% in the target language and 20% in English, never as blank space or a missing-key placeholder. As Inboard fills in the remaining strings, those slots switch over automatically on the next render — no change on your side.

Who manages translations

You don't. Translations are produced and maintained by Inboard against each platform's instruction set, not supplied per-customer. That keeps a guide consistent across every project that uses the same platform, and means adding a new language doesn't ask anything of you — when Inboard ships a locale, your existing embeds can use it immediately by passing the new tag.

If you need a language Inboard doesn't ship yet, let us know — locale coverage is data-driven and expands without any code change on the platform side.

See also

• Configuration — the data-locale attribute and the full Inboard.init() option list.
• Variables — pre-filling installer-specific values, which compose with any locale.