# 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 ``; `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 ``, 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](/docs/guides/branding) for fonts and tokens.