# Langues et écriture de droite à gauche Les pages destinées aux utilisateurs finaux (page de connexion hébergée, portail du compte, e-mails) sont disponibles en 30 langues. Trois d'entre elles s'écrivent de droite à gauche : l'arabe (`ar`), le persan (`fa`) et l'hébreu (`he`). Le tableau de bord et cette documentation sont disponibles en 8 langues : turc, anglais, français, allemand, coréen, japonais, italien et espagnol. ## Choix de la langue Les pages hébergées choisissent la langue à partir de ces sources, dans l'ordre. Chaque source est comparée aux langues dans lesquelles la page est traduite ; si aucune ne correspond, la source suivante est essayée : 1. Le paramètre `ui_locales` de la requête d'autorisation OIDC, sous forme de liste ordonnée (les 10 premières entrées). 2. L'en-tête `Accept-Language` du navigateur. Si aucune source ne correspond, l'anglais (`en`) est utilisé. Les balises de région reviennent à la langue de base (`de-AT` devient `de`). Les valeurs sont uniquement comparées, elles ne sont jamais recopiées dans la page. Les langues activées pour un environnement sont publiées sous forme de `ui_locales_supported` dans les métadonnées du fournisseur OpenID et sous forme de `locales` dans la réponse de `/fapi/v1/environment`, afin que votre application ne propose que ces langues. Les pages hébergées ne restreignent pas encore leur choix à cette liste, et la langue par défaut de l'environnement n'est pas encore utilisée comme solution de repli ; jusque-là, la solution de repli est toujours l'anglais. Pas encore disponible (prévu au plan §70) : un sélecteur de langue qui mémorise le choix dans un cookie `idp_locale`, et l'utilisation de la `locale` de l'utilisateur connecté. Tant que ces fonctions ne sont pas livrées, la langue est choisie à nouveau à chaque requête. ## Pages en écriture de droite à gauche - Chaque page hébergée et le portail du compte portent `` ; `dir` vaut `rtl` pour `ar`, `fa` et `he`. Les modèles d'e-mail portent le même `dir` sur leur élément racine. - Le CSS personnalisé n'accepte que les propriétés de direction logiques, telles que `margin-inline-start`, `padding-inline-end` et `border-inline-start`, ainsi que `text-align: start`. Les propriétés de direction physiques, telles que `margin-left`, sont rejetées avec `physical_property`, et les valeurs `left` et `right` avec `physical_value`. Les propriétés qui font passer un élément par-dessus un autre, y compris `position` et la famille `inset`, ne sont pas acceptées du tout. - Les champs du code à usage unique et du code de récupération sont toujours disposés de gauche à droite ; les champs d'identifiant utilisent `dir="auto"`, afin qu'une adresse conserve sa propre direction. - Le nom de l'application sur l'écran de consentement est isolé avec ``, afin qu'un nom écrit de gauche à droite ne perturbe pas une phrase de droite à gauche. Les autres noms, comme les noms d'organisation dans le sélecteur d'organisation, ne sont pas encore isolés. ## Caractères de contrôle bidirectionnels - Les noms d'affichage fournis par le client et présentés sur l'écran de consentement, comme le nom de l'application, sont débarrassés des caractères de contrôle, des caractères de format invisibles (y compris les contrôles bidi U+202A–U+202E et U+2066–U+2069) et des séparateurs de ligne ou de paragraphe, afin qu'un nom ne puisse pas réordonner ou falsifier le texte qui l'entoure. - Les remplacements de texte personnalisés dans la personnalisation rejettent les contrôles bidi U+202A–U+202E et U+2066–U+2069 avec le code d'erreur de champ `bidi_control_character`, et les autres caractères de contrôle avec `control_character` (`422 validation_failed` ; l'entrée `errors[]` pointe vers le texte). - Les valeurs de texte insérées dans les e-mails, comme le nom de l'application, sont rejetées si elles contiennent des caractères de contrôle ou des caractères de format invisibles ; le joiner et le non-joiner de largeur nulle (U+200D, U+200C) sont autorisés, car les écritures persane et indienne en ont besoin. ## Codes, dates et nombres Les codes à usage unique et les codes de récupération sont affichés avec des chiffres ASCII dans toutes les langues, car l'utilisateur peut les saisir sur un autre appareil. L'heure d'un événement de sécurité dans un e-mail utilise le format de date et d'heure CLDR de la langue de l'e-mail et le fuseau horaire du destinataire (UTC lorsqu'il est inconnu) ; une langue sans données de date CLDR affiche l'heure au format `YYYY-MM-DD HH:MM UTC`. ## Polices pour les autres écritures La liste des polices autorisées comprend les familles Noto Sans pour l'arabe, l'hébreu, le japonais, le coréen, le chinois simplifié, le thaï et le devanagari. Une famille pour le chinois traditionnel ne figure pas encore dans la liste (non vérifié). Voir [Personnaliser vos pages de connexion](/docs/guides/branding) pour les polices et les jetons.