Untitled

c15t ships with built-in translations for 30+ languages via the @c15t/translations package. Language detection happens automatically based on the browser's language preference, and you can override or extend translations for any language.

In c15t v2, the preferred config shape is i18n with locale, detectBrowserLanguage, and messages.

There are two ways c15t can load translations: client-side or server-side.

Server-sideClient-side
The best way to reduce bundle size and improve performance. We can detect the user's language based on the browser's language settings, allowing for the most accurate translations. By default, when using a inth.com hosted instance, these languages are supported.Bundled with the application allowing for multiple languages to be supported without the need for a backend. The more translations you have, the larger the bundle size will be, which may impact the performance of your application.

Translation Package Imports

Use the import path that matches your use case:

  • @c15t/translations: types, utilities, and enTranslations only (smallest client bundle)
  • @c15t/translations/en: English-only translation object
  • @c15t/translations/all: full baseTranslations map for all bundled locales

If you bundle translations client-side and need multiple languages, import from @c15t/translations/all explicitly:

Translation Sections

The Translations object is organized into sections:

SectionControls
commonShared button labels: acceptAll, rejectAll, customize, save
cookieBannerBanner title and description
consentManagerDialogDialog title and description
consentTypesPer-category title and description (keyed by AllConsentNames)
frameFrame placeholder title and button text (supports {category} placeholder)
legalLinksPrivacy policy, cookie policy, terms of service link text
iabIAB TCF banner, preference center, vendor list translations

Automatic Language Detection

By default, c15t detects the browser's language (navigator.language) and selects the closest matching translation. If custom messages are configured, fallback stays within your configured languages before using locale (or 'en') as the preferred fallback language.

When backend policy packs use i18n.messageProfile, the active language pool comes only from that resolved profile.

Example: if your Europe profile defines en, fr, and de, and your default profile defines en, es, and pt, a Europe visitor can resolve to en, fr, or de, but not es, pt, or zh.

Use profile-local fallbackLanguage inside backend i18n.messages to choose which configured language a policy profile should fall back to when the browser asks for an unsupported locale.

Disable auto-detection to always use locale:

If you need a policy to always use one specific language regardless of browser preference, set policy.i18n.language on the backend policy pack.

Override the title and description for individual consent categories:

Legacy translations Compatibility

The legacy syntax is still supported in 2.0 for RC compatibility:

If both are provided, i18n takes precedence.