Vous avez donc décidé de créer une version RTL de votre site. Peu importe ce qui vous motive: les exigences commerciales actuelles, ou vous prévoyez un tel besoin à l'avenir et souhaitez vous préparer, ou vous êtes simplement intéressé à plonger dans ce domaine du développement de l'interface utilisateur. L'important est que, très probablement, vous avez déjà rencontré des articles sur ce sujet, trouvé des plugins CSS pour développer les styles, vous êtes familiarisé avec la saisie de caractères dans les langues RTL et l'attribut magic dir.
Sinon, voici quelques liens utiles pour comprendre les problèmes et les solutions:
- De droite à gauche. Qu'est-ce que dir = rtl et comment apprivoiser l'arabe
- De droite à gauche. Comment inverser l'interface du site pour RTL
- RTL Styling 101 - Le guide ultime du style RTL en CSS
- Techniques d'internationalisation: création de HTML et CSS
- Bidirectionnalité dans la conception des matériaux
- Le blog d'André 小 山 Schappo sur l'internationalisation
Cela suffit pour essayer d'adapter les interfaces statiques pour RTL, et vous serez probablement très satisfait. Mais seulement jusqu'à ce que le site contienne des éléments d'interaction avec les utilisateurs, par exemple des formulaires pouvant accepter n'importe quel contenu quelle que soit la langue de l'interface.
Ce problème a deux composants - l'entrée et la sortie du contenu - et les deux sont intéressants à leur manière. Dans le même temps, le second est largement couvert dans les articles ci-dessus et dans d'autres, mais le premier ne l'est pas. Pour le résoudre, il y a plusieurs astuces qui nous ont semblé dignes de partager avec les lecteurs de Habr.
Tout d'abord, comparons quelques interfaces d'application RTL pour lesquelles les audiences RTL ne sont pas un gros problème, et voyons comment elles gèrent la tâche de saisie de texte.
Exemple 1. Un réseau social
1.1 Formulaire de connexion
Dans le formulaire de connexion de la page principale, le champ «E-mail» se comporte comme LTR par défaut. C'est assez raisonnable, car la plupart des adresses e-mail ne contiennent que des lettres latines.
Mais pas universellement. Les normes actuelles permettent à presque tous les caractères d'être utilisés dans les adresses e-mail. En conséquence, l'adresse écrite en hébreu sera:
- aligné à gauche;
- dans le processus d'écriture des symboles "@" et ".", qui ont un typage neutre, l'ensemble de la construction changera de position, ce qui n'est pas très pratique.
Le champ de mot de passe par défaut est RTL, le curseur se trouve à droite.
Mais que se passe-t-il si nous essayons de saisir un mot de passe à partir de caractères latins ou de chiffres? Au fur et à mesure que vous tapez, le curseur sera positionné à gauche du texte que vous entrez. Ce n'est pas critique, puisque nous ne voyons toujours pas le mot de passe (tant que nous n'avons pas le bouton "Afficher le mot de passe"), mais le comportement du champ pourrait être amélioré en montrant à l'utilisateur dans quelle disposition il entre le mot de passe. La spécificité des interfaces RTL est que, malgré le fait que la majeure partie du texte soit de droitier, les utilisateurs doivent très souvent changer de disposition de clavier pour entrer e-mail, login, mot de passe, qui sont généralement écrits LTR. Un petit conseil ici serait utile.
1.2 Formulaire d'inscription
Regardons maintenant le formulaire d'inscription, également situé sur la page principale.
Ici, vous pouvez voir que tous les champs sont clairement considérés comme RTL et sont alignés à droite, ce qui n'est pas très pratique lorsqu'il s'agit de texte LTR. Cela devient particulièrement désagréable lors de la saisie d'un e-mail - symboles «@» et «». forcer certaines parties de l'adresse à changer de place pendant le processus de numérotation. Ce qui n'était pas très critique pour les adresses RTL rares dans l'exemple précédent devient critique pour LTR.
1.3 Messenger - compact
Messenger est l'un des outils clés de cette application. Tout doit être parfait à coup sûr. Jetons un coup d'œil à la version compacte: en
effet. Le champ est considéré comme RTL par défaut, mais dès que nous commençons à taper du texte LTR, sa direction change en une entrée pratique. Ne rien sauter. Assurons-nous que tout est en ordre dans la version étendue également.
1.4 Messenger - développé
Oups! Bien que le texte latin dans le champ RTL se comporte correctement, il est justifié à droite. Ce n'est pas critique, mais la logique n'est pas claire: pourquoi le comportement du même composant idéologiquement est-il différent?
Apparemment, les quatre composants considérés ont été développés par différentes équipes ou à des moments différents, lorsque les exigences relatives aux interfaces internationales étaient différentes.
Y a-t-il quelque chose qui peut être amélioré ici? Nous le pensons. De plus, de manière très simple, à leur sujet - ci-dessous.
Exemple 2. Un service postal assez connu
2.1 Formulaire de connexion
Ici, les développeurs partent du principe de l'alignement à droite obligatoire, mais gardent l'attitude envers le contenu d'entrée comme LTR. Cela conduit à plusieurs points incommodes, similaires à ceux illustrés dans les exemples précédents.
Par exemple, un champ de saisie de courrier électronique attend du texte d'entrée à droite.
Cependant, le texte LTR entré se comporte comme prévu, sans aucun saut (et l'utilisation de caractères non latins dans ce service de messagerie est interdite).
, , RTL- , . , : - , - — , , , . Badoo, , .
Comportement plus intéressant pour le champ mot de passe. Il est également forcé d'être aligné à droite et est également considéré comme LTR, ce qui, à notre avis, entraîne la perte d'informations utiles sur la disposition du clavier lors de la saisie en langage RTL.
Et lorsque vous activez l'affichage du mot de passe, les choses deviennent vraiment mauvaises, car les caractères neutres font sauter le mot de passe, comme c'est le cas avec l'e-mail dans les exemples précédents. Ainsi, dans l'exemple de la capture d'écran suivante, le point d'exclamation doit venir en premier et le curseur doit être à gauche.
2.2
Formulaire d' inscription Le formulaire d' inscription est soudainement beaucoup plus convivial. Mais c'est logique - les informations qui y sont entrées sont plus diverses. Ici, au moins le prénom et le nom apparaissent.
L'alignement ici est également toujours aligné à droite, mais le texte n'est plus considéré sans ambiguïté à gauche et les champs changent de direction en fonction des caractères saisis.
La seule exception est le champ d'adresse. Ici, l'alignement est laissé. Ça a l'air un peu étrange.
Mais le champ du mot de passe est encore une fois frustrant. Malgré le fait que cette page a la capacité de changer dynamiquement la direction du texte dans les champs, pour une raison quelconque, elle n'a pas été ajoutée au champ du mot de passe.
Comme vous pouvez le voir, même des composants aussi simples soulèvent des questions. Que pouvons-nous dire à propos de contrôles complexes comme un calendrier?
Expérience Badoo
Sur la base des résultats de ce bref aperçu, nous formulerons les exigences relatives au comportement des champs de texte que nous aimerions obtenir:
- les espaces réservés doivent être alignés en fonction de la direction de la langue de l'interface;
- le texte saisi doit automatiquement occuper le côté gauche ou droit du champ, selon sa direction;
- le curseur dans un champ vide doit être aligné en fonction de la direction de la langue d'interface;
- texte entré dans les champs pour entrer le téléphone, l'URL doit toujours être sur le côté gauche;
- Les champs e-mail attendent du texte pour gaucher, mais sont également prêts pour les droitiers;
- les curseurs dans les champs vides pour l'e-mail, le téléphone, l'URL sont alignés à gauche.
Et essayons d'y parvenir.
Commençons par regarder un champ pour du texte brut, comme un nom, sans aucune astuce.
<html lang=”he” dir=”rtl”>
...
<input type="text">
...
</html>
Le curseur est positionné vers la droite comme prévu, car la balise INPUT hérite de la direction du texte du HTML, et pour une interface droitière, nous nous attendons à ce que le texte saisi soit très probablement droitier.
Mais que faire si nous commençons à taper des caractères LTR? La situation déjà familière avec un curseur inhabituel à gauche.
Dans les exemples ci-dessus, les développeurs adoptent une approche difficile pour résoudre le problème: ils surveillent les caractères d'entrée à l'aide de JavaScript et modifient l'attribut dir à la volée. Cela avait du sens jusqu'à récemment, mais maintenant tous les navigateurs modernes comprennent très bien l'attribut dir = "auto" et gèrent eux-mêmes le déroulement du texte. Ajoutons-le.
<input type="text" dir=”auto”>Il s'est avéré ce dont nous avions besoin.
Essayons d'ajouter un espace réservé au champ.
En général, l'utilisation des espaces réservés est un sujet distinct qui nécessite une familiarisation. Selon certains développeurs, l'utilisation irréfléchie de cet attribut nuit à la convivialité des champs d'entrée . En laissant la décision à vous, dans ces expériences, nous supposons que nous avons besoin d'espaces réservés.
<input type="text" dir=”auto” placeholder=”שם פרטי”>
Oh! Pour une raison quelconque, tout est aligné à gauche, y compris l'espace réservé.
Le point est dans l'attribut dir = "auto". En l'absence de contenu, le navigateur peut considérer que le sens du texte est gaucher. Essayons de placer des espaces réservés sur la bonne marge. Il s'agit généralement de texte dans la langue de l'interface, nous n'avons donc pas vraiment besoin de mise en page automatique.
input::placeholder {
direction: rtl;
}
Bien mieux. Seule la position du curseur prête à confusion - il est toujours à gauche. Essayons de styliser un INPUT vide avec la pseudo-classe lovely: placeholder-shown.
input:placeholder-shown {
direction: rtl;
}
Malheureusement, dans les entrées sans espace réservé, la propriété: placeholder-shown ne fonctionnera pas. Vous pouvez résoudre ce problème en ajoutant un espace réservé vide à tous ces champs:
<input type="text" dir=”auto” placeholder=” ”>Maintenant, tout est comme il se doit. Espace réservé à droite, curseur à droite (car nous attendons tout d'abord du texte RTL), texte - à droite ou à gauche, selon la langue dans laquelle nous imprimons.
Mais ce n'est pas assez.
Nous nous souvenons que les adresses e-mail peuvent contenir n'importe quel caractère. Par conséquent, le code d'une telle INPUT sera similaire au précédent.
<input type="email" dir=”auto” placeholder=”כתובת אימייל או מספר נייד”>(Sur Badoo, nous nous attendons, tout d'abord, à saisir un e-mail, mais nous autorisons également la saisie d'un numéro de téléphone, donc l'espace réservé en parle.)
Mais bien que les caractères puissent être quelconques, nous nous attendons tout d'abord à saisir l'adresse en latin (et dans notre cas, les chiffres les numéros de téléphone). Autrement dit, le curseur dans un champ vide doit être à gauche. Faisons une exception en CSS.
input[type='email']:placeholder-shown {
direction: ltr;
}Cela ne vaut pas la peine de s'y attarder. Nous avons encore des champs avec les types tel, number, url. Ils sont toujours gauchers, nous écrivons donc le code suivant pour eux:
<input type="tel" dir=”ltr” placeholder=”מספר טלפון”>Et ajoutez des exceptions pour les champs vides:
input[type='tel']:placeholder-shown,
input[type='number']:placeholder-shown,
input[type='url']:placeholder-shown {
direction: ltr;
}
Maintenant, c'est devenu comme nous l'avions prévu.
Juste une petite touche pour ceux qui se soucient d'IE11. Ce navigateur ne comprend pas l'attribut dir = "auto", de sorte que les changements automatiques de direction du texte ne peuvent pas être réalisés sans JavaScript.
Mais nous permettons toujours aux utilisateurs de saisir facilement des adresses e-mail et des numéros de téléphone.
.ie11 input[type="email"],
.ie11 input[type="tel"] {
direction: ltr;
}
.ie11 input[type="email"]:-ms-input-placeholder,
.ie11 input[type="tel"]:-ms-input-placeholder {
direction: rtl;
}
Si vous collectez tout le CSS, ajoutez des préfixes et le préprocesseur SCSS, vous obtenez quelque chose comme ceci (oui, nous nous souvenons que les champs INPUT peuvent, par exemple, être du type case à cocher, mais pour simplifier, nous ignorerons ce point):
[dir=”rtl”] input {
&::-webkit-input-placeholder {
direction: rtl;
}
&::-moz-placeholder {
direction: rtl;
}
&:-ms-input-placeholder {
direction: rtl;
}
&::placeholder {
direction: rtl;
}
&:placeholder-shown[type='email'],
&:placeholder-shown[type='tel'],
&:placeholder-shown[type='number'],
&:placeholder-shown[type='url'] {
direction: ltr;
}
}
.ie11 [dir=”rtl”] input {
&[type="email"],
&[type="tel"] {
direction: ltr;
&:-ms-input-placeholder {
direction: rtl;
}
}
}
Chez Badoo, nous divisons les styles en LTR et RTL, donc nous n'avons pas de cascade de [dir = ”rtl”], et nous écrivons les propriétés de LTR pour qu'elles se transforment en RTL. Mais le principe, je pense, est clair.
Pour TEXTAREA, le schéma est le même à une exception près: là, vous n'avez pas besoin de prendre en compte les types de champs et de placer le curseur ou le texte sur le bord gauche - le contenu est toujours automatiquement développé grâce à l'attribut dir = "auto".
Un point important à garder à l'esprit: toutes les exigences de terrain s'appliquent également aux interfaces LTR. Le nom saisi en hébreu ou en arabe doit être affiché à droite, le curseur doit être à gauche. Le rare fan d'une adresse e-mail exotique avec des caractères de droite devrait voir son e-mail au fur et à mesure qu'il le tape - de droite à gauche.
Bottom line: En ajoutant les bons attributs aux champs de saisie et quelques lignes de CSS, vous pouvez à un prix abordable, sinon adapter entièrement les formulaires aux langages droitiers, puis au moins améliorer considérablement leur convivialité en les rendant plus logiques et compréhensibles pour les utilisateurs.