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 <html lang=… dir=…> ; 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 <bdi>, 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 pour les polices et les jetons.