Vouch logoVouch
Resources

Data source localization

How Vouch renders data-source messages for non-English verifiers, and what verifiers see when a translation is missing.

Vouch renders the prose that the verifier sees — the proof-request title, the consent line, the topbar, the awaiting-proof overlay — in the verifier's language whenever a translation is available. This page explains what gets localized and what your end users see when a translation is missing.

What gets localized

Each data source carries an English source of truth (messages.subject plus the customSubject override when a wording variant is needed). Vouch renders the verifier-facing strings off those values:

FieldRendered where
nameProof-request card title, customer dashboard
descriptionProof-request card body, catalog
messages.consentConsent screen ("…will securely confirm…")
messages.topbarVerifier overlay topbar
messages.overlaySubtitle"Fetching … from …" overlay subtitle
messages.awaitingProof"is verifying …" status line

Operator-facing fields (category, type, geography, etc.) are not localized — they only appear in the Vouch catalog UI, which uses the operator's own browser language.

The full catalogue ships with English. Other locales are populated by an internal AI translator. An operator can override any field per locale from the data-source editor; those overrides are pinned and never overwritten by a later AI re-translation.

Supported locales

The current catalogue is published in:

  • en — English (default, source of truth)
  • pl — Polish

The set is intentionally short and grows on demand. Existing data sources keep working unchanged when a new locale ships — they just start serving the new language as soon as the backfill catches up.

Requesting a locale

Verifier-facing entry points (/prove and /api/proof-request-config) pick the response locale in this order:

  1. ?lang=<locale> query parameter, when present and in the supported set.
  2. The first supported tag in the Accept-Language header.
  3. en (the default) when neither resolves.

An unsupported ?lang= value falls through to Accept-Language rather than returning an error, so a stale or typo'd tag never breaks the flow.

Fallback behaviour

For each rendered field, Vouch resolves in this order:

overrides[key] ?? messages[key] ?? englishFallback(key)

Each step is independent per key, so a partial translation is a normal state — every missing key falls through to the English fallback on its own. Verifiers always see a coherent string; they never see an empty field or a translation token.

What this means in practice:

  • Locale not in catalogue (e.g. a request for de today): every key falls through to English. The proof-request card is fully readable.
  • Translation still pending for this row: keys that have never been translated fall through to English; keys that were filled by a prior successful translation keep their localized value.
  • Operator override on a field: the override wins, regardless of what the AI translator produced.