Languages and right-to-left

End-user pages (hosted login, account portal, emails) are available in 30 languages. Three of them are written right to left: Arabic (ar), Persian (fa) and Hebrew (he). The dashboard and this documentation are available in 8 languages: Turkish, English, French, German, Korean, Japanese, Italian and Spanish.

How the language is chosen

Hosted pages pick the language from these sources in order. Each source is matched against the languages the page is translated into; if nothing matches, the next source is tried:

1. The ui_locales parameter of the OIDC authorization request, as an ordered list (the first 10 entries).
2. The browser's Accept-Language header.

If neither source matches, English (en) is used. Region tags fall back to the base language (de-AT to de). The values are only matched, never copied into the page.

The languages enabled for an environment are published as ui_locales_supported in the OpenID Provider metadata and as locales in the /fapi/v1/environment response, so your application can offer only those. Hosted pages do not yet narrow their choice to that list, and the environment's default language is not yet used as the fallback; until then the fallback is always English.

Not available yet (plan §70): a language selector that remembers the choice in an idp_locale cookie, and using the locale of the signed-in user. Until they ship, the language is chosen again on every request.

Right-to-left pages

• Every hosted page and the account portal carry <html lang=… dir=…>; dir is rtl for ar, fa and he. Email templates carry the same dir on their root element.
• Custom CSS accepts logical direction properties only, such as margin-inline-start, padding-inline-end and border-inline-start, and text-align: start. Physical direction properties such as margin-left are rejected with physical_property, and the values left and right with physical_value. Properties that move an element over another one, including position and the inset family, are not accepted at all.
• One-time code and recovery code fields are always laid out left to right; identifier fields use dir="auto", so an address keeps its own direction.
• The application name on the consent screen is isolated with <bdi>, so a left-to-right name does not break a right-to-left sentence. Other names, such as the organization names in the organization picker, are not isolated yet.

Bidi control characters

• Customer-supplied display names shown on the consent screen, such as the application name, have control characters, invisible format characters (including the bidi controls U+202A–U+202E and U+2066–U+2069) and line or paragraph separators removed, so a name cannot reorder or spoof the text around it.
• Custom text overrides in branding reject the bidi controls U+202A–U+202E and U+2066–U+2069 with the field error code bidi_control_character and other control characters with control_character (422 validation_failed; the errors[] entry points at the text).
• Text values inserted into emails, such as the application name, are rejected if they contain control or invisible format characters; the zero-width joiner and non-joiner (U+200D, U+200C) are allowed because Persian and Indic scripts need them.

Codes, dates and numbers

One-time codes and recovery codes are shown with ASCII digits in every language, because the user may type them on another device. The time of a security event in an email uses the CLDR date and time format of the email's language and the recipient's time zone (UTC when it is not known); a language without CLDR date data shows the time as YYYY-MM-DD HH:MM UTC.

Fonts for other scripts

The allowed font list includes Noto Sans families for Arabic, Hebrew, Japanese, Korean, Simplified Chinese, Thai and Devanagari. A Traditional Chinese family is not on the list yet (not verified). See Brand your login pages for fonts and tokens.