The language switcher must be reachable before sign-in

What it is

A pre-authentication language switcher lets someone change interface language before they must understand sign-in, registration, verification, recovery, consent, or error content. It cannot depend on account settings or an application shell loaded only after authentication, and it cannot disappear behind a cookie-consent wall, regional gate, maintenance page, or network failure. It is an entry and recovery control, not an advanced profile preference.

Why it happens

When the initial language is wrong, a person may not recognize “sign in,” “forgot password,” or the failure reason. Requiring completion before switching creates a circular dependency. Pre-entry surfaces are also often owned separately by identity services, consent managers, CDN error templates, and the main app, so availability on a normal page proves little. A dependable implementation ships a minimal selector and supported language names in an unauthenticated bootstrap layer, with essential strings bundled alongside it. Selection performs no account mutation and does not depend on consent to nonessential tracking.

Studying it

Audit states rather than one page: first visit, sign-in, registration, verification, account recovery, invitation, consent wall, age or regional gate, expired session, forbidden access, 404/500, maintenance, offline, and language-bundle failure. In every state, record visibility, keyboard and screen-reader operability, recognition before switching, and whether errors and recovery actions update together. Start target-language participants who cannot read the default from deep links and failures; measure time to switch, wrong actions, recovery success, and abandonment without first pointing out the control.

Where it stops holding

Pre-auth reachability does not require duplicating a full list in every small component, but every blocking path must lead to one dependable selector. A security challenge, mandated notice, or third-party-hosted page may have partial translation only; disclose its content language and fallback rather than implying complete switching. Language changes must not bypass age, region, consent, authentication, or authorization gates, nor copy passwords, codes, or sensitive query parameters into links. Persistence depends on the storage and consent model, but switching the current page must not require agreement to nonessential tracking.

Applying it

• Put a keyboard-operable, accessibly named language entry in the unauthenticated shell. Sign-in, registration, recovery, consent, and error templates consume the same supported-language registry and minimal translation bundle.
• Keep it visible on narrow screens, under zoom, in RTL layout, with the software keyboard open, and beside error banners. Do not hide it only in a default-language footer, avatar menu, or post-login settings.
• Carry only the language and an allowlisted safe return location in switch links. Never copy passwords, verification codes, one-time tokens, or arbitrary redirect parameters, and reapply every gate and authorization check after switching.
• Maintain screenshot, keyboard, screen-reader, and end-to-end switching tests for every blocking state. If a language bundle fails, show a built-in autonym list and selector that needs no remote bundle, then give recovery instructions in an explicitly labeled fallback language, with multiple languages where needed. Report the specific failure instead of reverting to an incomprehensible blank page.

Related

• Same group: S4.01.1 Automatic language detection must be overrideable · S4.01.3 Display language names in their own language · S4.01.4 Preserve page and state after switching
• Adjacent: H6.01 Registration friction · H3.02 The three elements of an error message
• Search terms: pre-auth language switcher · localized sign-in · error-page localization