Sommaire
Cette section de la spécification traite de deux sujets importants en rappot avec l'internationalisation du HTML : la spécification de la langue (l'attribut lang) et la direction d'écriture du texte (l'attribut dir).
Les informations de langue peuvent être exploitées pour contrôler de multiples manières l'apparence d'un document balisé. Voici quelques situations où ces informations sont de quelque secours :
La valeur de l'attribut lang est un code de langue qui identifie la langue maternelle parlée, écrite, ou véhiculée sous toute autre forme par des êtres humains dans leur communication avec d'autres êtres humains. Les langages informatiques sont résolument exclus de cette codification de langues.
La [RFC1766] définit et explique les codes de langue qui doiventêtre utilisés dans les documents HTML.
En bref, les codes de langue consistent en un code primaire plus une liste éventuellemnt vide de sous-codes :
language-code = primary-code *( "-" subcode )
En voici quelques exemples :
Les deux lettres du code primaire sont réservés pour les abbréviations de langue conformes à l'[ISO639]. On trouvera parmi ces codes FR (Français), DE (Allemand), IT (Italien), NL (Néerlandais), EL (Grec), ES (Espagnol), PT (Portugais), AR (Arabe), HE (Hebreu), RU (Russe), ZH (Chinois), JA (Japonais), HI (Hindou), UR (Ourdou), et SA (Sanskrit).
Le sous-code à deux lettres est compris comme un code de pays conforme à la norme [ISO3166].
Un élément hérite des codes de langue des façons suivantes dans l'ordre de précédence (la plus haute à la plus faible):
Content-Language: fr-be
Dans l'exemple qui suit, le langage primitif du document est le français ("fr"). Un paragraphe est déclaré comme étant en espagnol ("es"), après lequel le langage primitif est restauré. Le paragraphe suivant contient une inclusion d'une phrase japonaise ("ja"), le langage primitif (français) étant finalement restauré jusqu'à la fin.
<HTML lang="fr"> <BODY> ...Interprétable en français... <P lang="es">...Interprétable en espagnol... <P>...de nouveau en français... <P>...texte français interrompu par <EM lang="ja">du japonais</EM> le texte termine en français... </BODY> </HTML>
Dans le contexte de HTML, un code de langue devrait toujours être interprété par un agent utilisateur plus comme une suite d'identificateurs que comme un seul. Lorsqu'un agent utilisateur ajuste sa présentation en fonction des informations de langue (disons par exemple, en comparant les codes de langue des feuilles de style avec les valeurs d'attributs lang), il s'attachera à toujours favoriser une correspondance exacte, mais devra tenter de faire correspondre le code primaire par défaut. De ce fait, si l'attribut lang est défini à "en-US" pour un élément HTML, un agent utilisateur recherchera les feuilles de style qui correspondent d'abord exactement à la langue "en-US", puis recherchera celles répondant à la mention plus générale "en".
Note : La hiérarchie des codes de langue ne garantit pas que toutes les langues définies comme ayant le même préfixe seront compréhensibles avec le même degré de fluidité par l'utilisateur. Mais elle permet d'appeler des caractères communs lorsque ceux-ci ont une signification pour l'utilisateur.
Pour des langues artificielles telles que le Troll, l'Elfe ou le Klingon, le fait de vouloir utiliser l'attribut lang pour séparer ces "langues" du reste du texte n'est pas totalement dénué de sens. En attendant qu'un digne successeur de la [RFC1766] ne définisse une manière standardisée pour ce faire, une possibilité reste d'ultiliser le préfixe conventionnel x-, par exemple x-troll.
En plus de spécifier la langue primitive d'un document, les auteurs pourront spécifier la direction d'écriture de texte par défaut pour des tronçons de texte, ou le document entier.
La spécification de l'[UNICODE] assigne une "directionnalité" aux caractères Unicode et définit un algorithme (complexe) pour déterminer la directionnalité effective d'un bloc de texte. Pour un document ne contenant rien qui n'ait besoin d'être affiché de droite à gauche, un agent utilisateur conforme pourra se passer d'utiliser l'algorithme bidirectionnel d'[UNICODE]. Dès qu'un document contient au moins un caractère défini pour l'affichage de droite à gauche, et si l'agent utilisateur est configuré pour afficher ces caractères, l'agent utilisateur conforme sera tenu d'utiliser cet algorithme bidirectionnel.
Bien que Unicode spécifie des caractères spéciaux gérant la directionnalité, le HTML propose aussi des balises de plus haut niveau qui permettent également de gérer cette directionnalité : les attributs dir (à ne pas confondre avec l'élément DIR) et l'élément BDO. De ce fait, pour représenter une citation en Hébreu, il sera plus intuitif d'écrire
<Q lang="he" dir="rtl">...une citation en hébreu ...</Q>
plutôt que la référence équivalente selon la définition Unicode :
‫״...une citation en hébreu...״‬
Les agents utilisateurs ne devront pas utiliser l'attribut lang pour déterminer la direction du texte.
En absence de contredéfinitions locales, la direction par défaut est héritée de celle de l'élément "englobant".
L'exemple suivant illustre le comportement attendu de l'algorithme bidirectionnel.
Considérons l'exemple de texte suivant :
français1 HEBREU2 français3 ARABE4 français5 HEBREU6
Les caractères dans cet exemple (et tous les exemples afférents) sont stockés par l'ordinateur dans l'ordre où ils sont présentés ici : le premier caractère du fichier est le "f", le deuxième le "r", et le dernier le "6".
Supposons que la langue prédominante dans ce document contenant ce paragraphe soit le français (direction primitive de gauche à droite). La présentation correcte de cette ligne serait :
français1 2UERBEH français3 4EBARA français5 6UERBEH
------- ------ -------
H H H
----------------------------------------------------
E
Les lignes brisées indiquent la structure de la phrase : le français prédomine et du texte hébreu et arabe y est cité. Obtenir une représentation correcte ne nécessite en principe aucun marquage additionnel dans la mesure où les fragments hébreus et arabes serotn dûment inversés par des agents utilisateurs conformaes appliquant l'algorithme bidirectionnel.
Si, par contre, la langue prédominante est l'hébreu ou l'arabe (direction primitive droite vers gauche), la présentation correcte de la phrase est :
6UERBEH français5 4EBARA français3 2UERBEH français1
--------- --------- ---------
E E E
--------------------------------------------------
H
Dans ce cas, la phrase entière est présentée de droite à gauche et les séquences françaises incluses seront dûment inversées par l'algorithme bidirectionnel.
L'algorithme bidirectionnel de l'Unicode nécessite la définition d'une direction primitive d'écriture de texte. Pour définir la direction de base d'un élément de niveau "bloc", on définira l'attribut dir. Par défaut, cet attribut est initialisé à "ltr" (texte écrit de gauche à droite).
Lorsque l'attribut dir est défini dans un élément de niveau "bloc", son effet demeure jusqu'à la fin de l'élément de niveau "bloc" et est transmis à tout élément de niveau "bloc" qu'il contiendrait. Le fait de définir localement l'attribut dir dans un élément inclus contrarie la valeur héritée.
Pour définir la direction primitive d'écriture de texte pour le document entier, définissez l'attribut dir de l'élément HTML lui-même.
Par exemple :
<HTML dir="RTL"> ...ehcuag à etiord ed etxet... <P dir="ltr">...texte de gauche à droite...</P> <P>...ehcuag à etiord ed etxet ud erocne...</P> </HTML>
Par opposition, les élements "en ligne" n'héritent pas de l'attribut dir. Ceci signifie qu'un élément "en ligne" sans définition de l'attribut dir ne participe pas au principe hiérarchique d'inclusion géré par l'algorithme bidirectionnel.
L'algorithme bidirectionnel de l'[UNICODE] inverse automatiquement les séquences de caractères incluses d'après leur directionnalité inhérente (comme montré dans les exemples précédants). Cependant, ce principe ne peut gérer qu'un seul niveau d'imbrication de texte. Pour permettre plusieurs niveaux d'imbrication et de changements de directionnalité, il est nécessaire de disposant d'un élément "en ligne" admettant l'attribut dir.
Considérons le même exemple que précédemment :
français1 HEBREU2 français3 ARABE4 français5 HEBREU6
Supposons que la langue prédominante du document contenant ce paragraphe est le français et que notre exemple est le résultat d'inclusions suivantes : la phrase française ci-dessus contient une citation d'un diccionnaire allant de HEBREU2 à ARABE4. Cet extrait contient une citation dela traduction française (français3). La présentation souhaîtée pour cette phrase est :
français1 4UERBEH français3 2EBARA français5 6UERBEH
---------
E
------------------------
H
----------------------------------------------------
E
Afin d'obtenir les directions de direction d'écriture de texte voulus, il nous faudra donner des informations supplémentaires, en délimitant la seconde inclusion de façon explicite. Dans cet exemple, Nous utilisons l'élément SPAN (neutre par défaut pour la présentation) avec un attribut dir :
français1 <SPAN dir="RTL">HEBREU2 français3 ARABE4</SPAN> français5 HEBREW6
Les auteurs pourront également utiliser les caracères spéciaux Unicode réservés au pilotage de la direction de texte pour obtenir le même effet dans les imbrications à multiple niveau. Pour obtenir une inclusion de texte de gauche à droite, on encadrera le texte des deux caractères LEFT-TO-RIGHT EMBEDDING ("LRE", 202A en hexa) et POP DIRECTIONAL FORMATTING ("PDF", 202C en hexa). Pour obtenir une inclusion de droite à gauche, encadrez le texte des caractères RIGHT-TO-LEFT EMBEDDING ("RTE", hexadecimal 202B) et PDF.
Mélanger les balises HTML de direction et les caractères Unicode. Les auteurs de pages et concepteurs d'outils d'édition doivent garder à l'esprit que des conflits peuvent naître de l'utilisation concurentielle de l'attribut dir, défini pour des éléments "en ligne" (y compris BDO), et des caractères de contrôle du texte correspondant de la définition [ISO10646]. Il est largement préférable de n'utiliser exclusivement qu'un seul des deux systèmes. La méthode par balises HTMl garantit une meilleure intégrité structurelle et ôte quelques soucis lorsque le texte HTMl bidirectionnel est édité par des traitements de textes simples, mais certaines applications semblent être plus aptes à traiter les caractères de formatage selon l'[ISO10646]. Si par hasard les deux méthodes devaient être utilisées, on devra porter une attention toute particulière aux imbrications des inversions de sens balisées et codées, faute de quoi l'on ne peut préjuger de la représentation obtenue.
<!ELEMENT BDO - - (%inline)* -- I18N BiDi over-ride --> <!ATTLIST BDO lang NAME #IMPLIED -- code de langue selon la [RFC1766] -- dir (ltr|rtl) #REQUIRED -- direction -- >
Balise de début : requise, Balise de fin : requise
Attributs définis par ailleurs
L'algorithme bidirectionnel et l'attribut dir suffisent en général à gérer les inclusions avec changement de direction d'écriture de texte. Il existe cependant quelques situationsdans lesquelles l'utilisation de l'algorithme bidirectionnel provoque une représentation incorrecte. L'élément BDO permet aux auteurs de désactiver l'algorithme bidirectionnel pour certains fragments de texte.
Considerons un document français contenant le même texte que précédemment :
français1 HEBREU2 français3 ARABE4 français5 HEBREU6
Supposons en outre que cette séquence est lue par un agent utilisateur de gauche à droite (le flusx d'octets commence par le caractère "f" pour se terminer par le caractère "6"). Le "f" dans "français1" est à gauche du "a", ce qui correspond bien au sens dans lequel les auteurs saisissent les caractères des mots français. Cependant, le "H" de "HEBREU2" est également à gauche du "E", ce qui ne correspond pas forcément à la manière dont les auteurs saisissent les documents en hébreu. Par exemple, le standard MIME ([RFC2045]) préconise que des séquences de caractères d'une écriture de droite à gauche des email doit se trouver aussi ordonnée de droite à gauche dans le flux de caractères. Cette spécification entre en conflit avec l'algorithme bidirectionnel de l'[UNICODE], qui s'attend à ce que les caractères hébreus soit ordonnés de gauche à droite.
De ce fait, si la séquence "HEBREU4" de l'exemple ci-avant est un extrait d'un courrier électronique rédigé en hébreu, sa structure dans le fichier serait "4UERBEH". Un agent utilisateur appliquant l'algorithme bidirectionnel afficherait cette séquence dans l'ordre inverse.
La solution la plus simple dans ce cas est de désactiver l'algorithme bidirectionnel en insérant l'extrait de courrier hébreu dans un élément BDO, dont l'atribut dir sera initialisé à "LTR" :
français1 HEBREU2 français3 <BDO dir="LTR">4UERBEH</BDO> français5 HEBREU6
Ceci indiquerait à l'algorithme bidirectionnel quelque chose du style "Laisse moi de gauche à droite !" et produirait la présentation désirée :
français1 2UERBEH français3 4UERBEH français5 6UERBEH
L'élément BDO devra être utilisé dans les situations où un contrôle absolu sur l'ordre des séquences d'affichage est nécessaire (ex., numérotations multilingue). L'attribut dir est obligatoire pour cet élément.
Les auteurs pourront également utiliser les caractères spéciaux Unicode pour désactiver l'algorithme bidirectionnel --- LEFT-TO-RIGHT OVERRIDE (202D) ou RIGHT-TO-LEFT OVERRIDE (202E). Le caractère POP DIRECTIONAL FORMATTING (202C) termine une zone de désactivation de l'algorithme bidirectionnel.
Note : Souvenez-vous que des conflits peuvent naître de l'utilisation concurente d'éléments "en ligne" associés à un attribut dir (BDO compris) et des caractères de contrôle de format conséquents de l'[ISO10646].
Bidirectionalité et encodage des caractères Selon les [RFC1555] et [RFC1556], il existe des conventions particulières d'utilisation de valeurs de "charset" pour définir le traitement bidirectionnel des courriers MIME, en particulier, afin de différencier la directionnalité rendue par formatage visuel, implicite, et explicite. La valeur "iso-8859-8" (pour l'hébreu) vaut pour un encodage visuel, "iso-8859-8-i" pour une bidirectionalité implicite, et "iso-8859-8-e" pour une directionalité explicite.
| NdT. J'avoue qu'en ce point cette note n'est pas d'une clarté absolue. Les paragraphes suivants donnent quelques éléments complémentaires qui peuvent servir de "pistes" au lecteur. Les lecteurs plus assidus se reporteront aux documents officiels de l'ISO concernant la définition des jeux de caractères normalisés, pour approfondir les notions évoquées ici |
Comme le HTML utilise l'algorithme bidirectionnel de l'Unicode dans sa définition complète, les documents conformes devront être labelisés "iso-8859-8-e". La directionnalité implicite est un sous-ensemble de l'algorithme Unicode complet, et la valeur "iso-8859-8-i" sera de ce fait également acceptée, même s'il est préférable de ne pas l'utiliser.
La valeur "iso-8859-8" indique que le document est formaté visuellement (?), en utilisant à défaut d'autre possibilité certaines balises (telles qu'une TABLE avec alignement à droite sans rebouclage de ligne) à fin de s'assurzer d'une représentation acceptable par des agents utilisateurs plus anciens qui ne savent pas gérer la directionnalité du texte. De tels documents ne sont évidemment pas conformes à la présente spécification. Il pourra être fait en sorte de rendre ces documents conformes à la présente (si nécessaire, et tout en conservant une apparence correcte sur d'anciens agents) en ajoutant des balises BDO le cas échéant. Contrairement à ce qui est dit dans les [RFC1555] et [RFC1556], l'iso-8859-6 (Arabe) n'est pas dans l'ordre visuel.
Comme certaines ambiguïtés peuvent apparaître quant à la directionnalité de certains caractères (ex., dans certaines situations en Arabe), la spécification [UNICODE] inclue des caractères spéciaux pour autoriser un contrôle de la résolution. Le HTML 4.0 inclue un ensemble d'entités caractères nommées qui permettent un support partiel de l'algorithme bidirectionnel Unicode, plus des fonctionnalités particulières aux langues nécessitant une analyse contextuelle avant représentation.
L'extrait suivant de la DTD présente certaines des entités directionnelles :
<!ENTITY zwnj CDATA "‌"--=zero width non-joiner--> <!ENTITY zwj CDATA "‍"--=zero width joiner--> <!ENTITY lrm CDATA "‎"--=left-to-right mark--> <!ENTITY rlm CDATA "‏"--=right-to-left mark-->
L'entité zwnj est utilisée pour disjoindre des blocs dans des contextes où une jonction arrive à tort. L'entité zwj fait exactemetn le contraire ; elle force la jonction là où elle ne se produit pas (et aurait dû se produire). Par exemple, la lettre arabe "HEH" est utilisée comme abbréviation du mot "Hijri", le nom du calendrier Islamique. Vomme la forme isolée du caractère "HEH" ressemble au chiffre 5 tel qu'employé dans l'écriture arabe (sur la base des digits Indic), il est nécessaire de prévenir toute confusion entre ce "HEH" et un chiffre 5 terminant le numéro de l'année. Pour cela la forme originale du caractère "HEH" est utilisée. Cependant, il n'existe aucun contexte pouvant suivre la lettre "HEH" (c-à-d., une letter que l'on puisse lui adjoindre). L'entité zwj permet de résoudre le problème et outrepasser cette impossibilité.
Similairement, dans les textes Persans, il existe des cas dans lesquels une lettre qui normalement se joindrait à une autre par une connexion cursive (un tracé de liaison) doit justement s'écrire sans cette liaison. Le caractère zwnj est utilisé dans ce cas pour disjoindre cette lettre de la suivante, sans créer d'espacement entre les lettres pour autant.
Les autres caractères lrm et rlm, serotn utilisés pour ôter l'ambiguîté sur la directionnalité. Par exemple, si un guillemet intervient entre un caractère arable et un caractère latin, la direction d'écriture du guillemet est ambigüe (le guillemet est-il à considérer comme faisant partie de la section arabe ou latine?). Les caractères lrm et rlm ont une propriété directionnelle mais aucune largeur graphique ni aucune propriété de rupture de ligne. Reportez-vous à la spécification de l'[UNICODE] pour plus de détails.
Glyphes inversées : L'algrithme bidirectionnel inverse la présentation de certains ensembles de caractères notoires tels que les parenthèses (voir la spécification [UNICODE], table 4-7). Hormis ces caractères, le traitement de la bidirectionnalité laisse la forme de chacun des glyphes inchangée. Ainsi, si vous souhaitez affichier le mot "MURDER" telq u'il serait vu dans un miroir (caractères de droite à gauche et glyphes inversées), vous pourriez utiliser un élément BDO associé à un attribut dir définissant la direction de texte de droite à gauche, ex.,
<BDO class="mirror" dir="rtl">MURDER</BDO>
et la valeur de classe "mirror" associée à une règles spécifique de la feuille de style pour sélectionner une police spéciale qui afficherait les glyphes inverses de tous les caractères.
En général, passer d'une définition d'affichage d'un élément en mode bloc à son affichage en mode "en ligne" dans une feuille de style est trivial. Cependant, parce que la différence entre les éléments de niveau "bloc" et "en ligne" est particulièrement significative en matière de bidirectionnalité, une attention particulière devra être apporté pour le codage.
Lorsqu'un élément "en ligne" ne disposant pas d'attribut dir est transformé en un élément de niveau bloc par une feuille de style, il hérite de l'attribut dir du premier élément qui l'englobe comme définition primitive pour ce bloc.
Lorsqu'un élément de niveau "bloc" exempt de définition d'attribut dir est transmuté en élément "en ligne" par une feuille de style, la présentation resultante devrait en être équivalente, en temres de formatage directionnel, à celle obtenue en ajoutant un attribut explicite dir (initialisé à la valeur héritée) à l'élément ainsi transformé.
Des agents utilisateurs peuvent être dans l'incapacité de représenter de façon significative toutes les valeurs de caractères utilisées, par exemple, parce qu'une police approprié fait défaut, ou en cas de présence d'un caractère dont la valeur n'est pas représentable selon l'encodage interne.
Comme il est possible d'envisager une multitude d'attitudes différentes dans une telle situation, ce document ne précise aucun comportement particulier. Suivant l'implémentation, ced cas pourra être traité directement par le dispositif d'affichage lui-même plutôt que par l'application. Cette spécification recommande néanmoins d'envisager les comportements suivants :