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:
| Field | Rendered where |
|---|---|
name | Proof-request card title, customer dashboard |
description | Proof-request card body, catalog |
messages.consent | Consent screen ("…will securely confirm…") |
messages.topbar | Verifier 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:
?lang=<locale>query parameter, when present and in the supported set.- The first supported tag in the
Accept-Languageheader. 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
detoday): 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.