La version française de cette traduction est :
http://www.la-grange.net/w3c/html4.01/
Traducteur : Claude Chaunier dans le cadre de l'effort de la liste de discussion w3c-translators.fr@w3.org
La version française peut contenir des erreurs. La version anglaise de cette note est l'unique version
normative. Version originale : http://www.w3.org/TR/1999/REC-html401-19991224
Sommaire
Cette section du document traite de deux sujets importants qui ont des répercussions sur l'internationalisation de HTML : spécifier la langue (l'attribut lang) et la direction (l'attribut dir) du texte dans un document.
L'indication de langue faite au moyen de l'attribut lang peut être utilisée par un agent utilisateur pour contrôler la restitution de diverses manières. L'auteur qui fournit cette information peut notamment :
L'attribut lang spécifie la langue du contenu de l'élément et celle des valeurs d'attribut ; que celui-ci s'applique ou non à un attribut dépend de la syntaxe et de la sémantique de l'attribut en question, et de l'opération en jeu.
Le but de l'attribut lang est de permettre aux agents utilisateurs de représenter un contenu de façon plus pertinente en suivant les pratiques culturelles en usage dans une langue donnée. Ceci ne veut pas dire que les agents utilisateurs devraient représenter de façon moins pertinente les caractères qui seraient atypiques pour une langue particulière, ; les agents utilisateurs doivent faire de leur mieux pour représenter tous les caractères, quelle que soit la valeur spécifiée par lang.
Par exemple, si des caractères de l'alphabet grec apparaissent au milieu d'un texte en français :
<P><Q lang="fr">Ses super-pouvoirs étaient la conséquence d'un rayonnement γ</Q>, expliqua-t-il.</P>
l'agent utilisateur (1) devrait s'efforcer de représenter le contenu français de manière appropriée (dans sa façon de gérer les guillemets par exemple) et (2) doit faire son possible pour représenter le caractère « γ » même si ce n'est pas un caractère français.
Veuillez consultez la section sur les caractères non affichables pour un complément d'information.
La valeur de l'attribut lang est un code de langue qui identifie une langue parlée, écrite, ou utilisée d'une manière ou d'une autre pour la communication d'informations entre personnes. Les langages informatiques sont explicitement exclus des codes de langue.
Le document [RFC1766] définit et explique les codes de langue qui doivent être utilisés dans les documents HTML.
Brièvement, les codes de langues consistent en un code principal et une suite éventuellement vide de sous-codes :
code-de-langue = code-principal ( "-" sous-code )*
Voici des exemples de codes de langue :
Les codes principaux de deux lettres sont réservés aux abréviations de langues [ISO639]. Parmi les codes de deux lettres, citons : "en" (anglais), "de" (allemand), "it" (italien), "nl" (néerlandais), "el" (grec), "es" (espagnol), "pt" (portugais), "ar" (arabe), "he" (hébreu), "ru" (russe), "zh" (chinois), "ja" (japonais), "hi" (hindi), "ur" (ourdou) et "sa" (sanscrit).
Tout sous-code de deux lettres est considéré comme étant un code de pays [ISO3166].
Un élément hérite de l'indication du code de langue selon l'ordre de priorité suivant (de la priorité la plus élevée à la plus faible) :
Content-Language: fr-CA
Dans cet exemple, la langue principale du document est le français ("fr"). Un paragraphe est déclaré être en espagnol ("es"), après lequel la langue principale redevient le français. Le paragraphe qui vient ensuite inclut une phrase enchâssée en japonais ("ja"), après laquelle la langue principale redevient le français.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<HTML lang="fr">
<HEAD>
<TITLE>Un document multilingue</TITLE>
</HEAD>
<BODY>
...Interprété comme du français...
<P lang="es">...Interprété comme de l'espagnol...
<P>...À nouveau interprété comme du français...
<P>...Texte français interrompu par<EM lang="ja">du
japonais</EM>Le français reprend ici...
</BODY>
</HTML>
Dans le contexte de HTML, un code de langue devrait être interprété par les agents utilisateurs comme une hiérarchie d'atomes plutôt qu'un seul atome. Quand l'agent utilisateur ajuste la restitution en fonction des indications de langue (disons, en comparant les codes de langue de la feuille de style et les valeurs de l'attribut lang), il devrait toujours donner la préférence aux codes qui coïncident parfaitement, mais il devrait aussi envisager la correspondance des codes principaux comme étant suffisante. De cette manière, si l'attribut lang est spécifié pour l'élément HTML avec la valeur "fr-CA", l'agent utilisateur devrait préférer les indications de style qui correspondent d'abord à "fr-CA", puis à la valeur plus générale "fr".
Remarque : Les hiérarchies de codes de langue ne garantissent pas que toutes les langues ayant un même préfixe seront comprises par ceux qui lisent couramment une ou plusieurs de ces langues. Elles permettent néanmoins à l'utilisateur de se prévaloir de cette parenté lorsque c'est le cas pour lui.
Définition de l'attribut
En plus de spécifier la langue d'un document avec l'attribut lang, les auteurs peuvent avoir besoin de spécifier la directionnalité de base (de gauche à droite ou de droite à gauche) de certaines parties du texte d'un document, de la structure d'une table, etc. Cela se fait avec l'attribut dir.
La spécification [UNICODE] attribue une directionnalité aux caractères et définit un algorithme (complexe) pour déterminer la directionnalité correcte d'un texte. Si un document ne contient pas de caractère affichable droite à gauche, l'agent utilisateur conforme n'est pas tenu d'appliquer l'algorithme bi-directionnel [UNICODE]. Si un document contient des caractères droite à gauche, et si l'agent utilisateur affiche ces caractères, l'agent utilisateur doit utiliser l'algorithme bi-directionnel.
Bien que la norme Unicode spécifie des caractères spéciaux qui concernent la direction du texte, HTML offre des structures de balisage de niveau supérieur qui font la même chose : l'attribut dir (à ne pas confondre avec l'élément DIR) et l'élément BDO. Ainsi, pour faire une citation en hébreu, il est plus intuitif d'écrire ceci :
<Q lang="he" dir="rtl">...une citation en hébreu...</Q>
que l'équivalent faisant appel à des caractères Unicode :
‫״...une citation en hébreu...״‬
Les agents utilisateurs ne doivent pas utiliser l'attribut lang pour déterminer la direction du texte.
L'attribut dir est hérité et il peut être surclassé. Veuillez consulter la section sur l'héritage des indications de direction du texte pour des précisions.
L'exemple qui suit illustre le comportement attendu de l'algorithme bi-directionnel. Il met en jeu du français, une langue écrite de gauche à droite, et de l'hébreu, une langue écrite de droite à gauche.
Considérons l'exemple de texte suivant :
français1 HÉBREU2 français3 HÉBREU4 français5 HÉBREU6
Les caractères de cet exemple (et de tous les exemples similaires) sont rangés dans l'ordinateur dans l'ordre où ils sont affichés ici : le premier caractère du fichier est "f", le deuxième est "r", et le dernier est "6".
Supposons que la langue prédominante du document contenant ce paragraphe soit le français. Cela signifie que la direction de base est de gauche à droite. La représentation correcte de cette ligne serait :
français1 2UERBÉH français3 4UERBÉH français5 6UERBÉH
<------ <------ <------
h h h
---------------------------------------------------->
f
Les lignes en pointillés indiquent la structure de la phrase : le français prédomine, et du texte en hébreu se trouve enchâssé. Obtenir la bonne représentation ne nécessite pas de balises supplémentaires puisque les passages en hébreu sont correctement inversés par les agents utilisateurs qui appliquent l'algorithme bi-directionnel.
Inversement, si la langue prédominante du document est l'hébreu, la direction de base est de droite à gauche. La représentation correcte est alors :
6UERBÉH français5 4UERBÉH français3 2UERBÉH français1
--------> --------> -------->
f f f
<----------------------------------------------------
h
Dans ce cas, la phase entière a été représentée allant de droite à gauche et les séquences enchâssées en français ont été correctement inversées par l'algorithme bi-directionnel.
L'algorithme bi-directionnel Unicode exige une direction de base pour les blocs de texte. Pour spécifier la direction de base d'un élément de bloc, donnez une valeur à l'attribut dir de l'élément. La valeur par défaut de l'attribut dir est "ltr" (texte de gauche à droite).
Quand l'attribut dir est spécifié pour un élément de bloc, il reste valable tout au long de l'élément et pour tout élément de bloc emboîté. Une valeur donnée à l'attribut dir sur un élément emboîté a priorité sur la valeur héritée.
Pour spécifier la direction de base du texte dans tout un document, donnez une valeur à l'attribut dir sur l'élément HTML.
Par exemple :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML dir="RTL"> <HEAD> <TITLE>...un titre allant de droite à gauche...</TITLE> </HEAD> ...texte allant de droite à gauche... <P dir="ltr">...texte allant de gauche à droite...</P> <P>...encore un texte de droite à gauche...</P> </HTML>
Les éléments en-ligne, par contre, n'héritent pas de l'attribut dir. Cela signifie qu'un élément en-ligne, sans l'attribut dir, n'ouvre pas de niveau d'enchâssement supplémentaire, en ce qui concerne l'algorithme bi-directionnel. (Ici un élément est considéré comme étant de type bloc ou bien en-ligne en fonction de sa représentation par défaut. Remarquez que les éléments INS et DEL peuvent être de type bloc ou en-ligne, selon le contexte.)
L'algorithme bi-directionnel [UNICODE] inverse automatiquement les séquences de caractères enchâssées en fonction de leur directionnalité inhérente (comme l'illustrent les exemples précédents). Cependant, un seul niveau d'enchâssement peut généralement être pris en compte. Pour obtenir des niveaux supplémentaires de changements de direction enchâssés, vous devez faire usage de l'attribut dir sur un élément en-ligne.
Considérons le même exemple de texte que précédemment :
français1 HÉBREU2 français3 HÉBREU4 français5 HÉBREU6
Supposons que la langue prédominante du document contenant ce paragraphe soit le français. En outre, supposons que la phrase en français ci-dessus contienne un segment en hébreu, allant de « HÉBREU2 » à « HÉBREU4 », et que le segment en hébreu contienne à son tour une citation en français (« français3 »). La représentation désirée du texte est ainsi :
français1 4UERBÉH français3 2UERBÉH français5 6UERBÉH
-------->
F
<------------------------
H
---------------------------------------------------->
F
Pour réaliser deux changements de direction enchâssés, on doit fournir des indications supplémentaires, ce que l'on fait en délimitant le second enchâssement de manière explicite. Dans cet exemple, on utilise l'élément SPAN et l'attribut dir pour baliser le texte :
français1 <SPAN dir="RTL">HÉBREU2 français3 HÉBREU4</SPAN> français5 HÉBREU6
Les auteurs peuvent aussi utiliser des caractères spéciaux Unicode pour réaliser ces multiples changements de direction enchâssés. Pour réaliser un enchâssement allant de gauche à droite, entourez le texte enchâssé des caractères « ENCHÂSSEMENT GAUCHE-À-DROITE » ("LRE", code 202A en hexadécimal) et « DÉPILEMENT DE FORMATAGE DIRECTIONNEL » ("PDF", code 202C en hexadécimal). Pour réaliser un enchâssement allant de droite à gauche, entourez le texte enchâssé des caractères « ENCHÂSSEMENT DROITE-À-GAUCHE » ("RLE", code 202B en hexadécimal) et « PDF ».
L'utilisation du balisage de directionnalité HTML avec des caractères Unicode. Les auteurs et les développeurs de logiciels d'édition doivent doivent garder à l'esprit que des conflits peuvent survenir si on utilise l'attribut dir sur des éléments en-ligne (y compris l'élément BDO) en même temps que les caractères de formatage [UNICODE] correspondants. On utilisera de préférence l'une ou l'autre méthode de manière exclusive. La méthode avec les balises offre une meilleure assurance d'intégrité structurelle des documents et allège certaines difficultés lorsqu'on prépare un texte HTML bi-directionnel avec un simple éditeur de texte, mais certains logiciels peuvent être plus aptes à utiliser les caractères [UNICODE]. Si les deux méthodes sont utilisées, on exercera le plus grand soin à imbriquer correctement le balisage et l'enchâssement ou inactivation directionnels, sinon les conséquences sur la restitution seront indéfinies.
<!ELEMENT BDO - - (%inséré;)* -- inactivation BiDi I18N --> <!ATTLIST BDO %attrsdebase; -- id, class, style, title -- lang %CodeLangue; #IMPLIED -- code de langue -- dir (ltr|rtl) #REQUIRED -- directionnalité -- >
Balise ouvrante : obligatoire, Balise fermante : obligatoire
Définition des attributs
Attributs définis ailleurs
L'algorithme bi-directionnel et l'attribut dir suffisent généralement à gérer les changements de direction enchâssés. Il peut toutefois se présenter des situations où l'application de l'algorithme bi-directionnel aboutit à une représentation incorrecte. L'élément BDO permet aux auteurs d'inactiver l'algorithme bi-directionnel sur des passages voulus du texte.
Considérons un document contenant le même texte que précédemment :
français1 HÉBREU2 français3 HÉBREU4 français5 HÉBREU6
Mais, supposons que ce texte ait déjà été rangé visuellement. Ceci peut-être parce que la norme MIME ([RFC2045], [RFC1556]) favorise le rangement visuel, i.e., que les séquences de caractères droite-à-gauche sont insérées de droite à gauche dans le flux d'octets. Dans un courrier électronique, ce qui précède pourrait être mis en forme, sauts de ligne compris, tel que :
français1 2UERBÉH français3 4UERBÉH français5 6UERBÉH
Ceci entre en conflit avec l'algorithme bi-directionnel [UNICODE], parce que l'algorithme inverserait « 2UERBÉH », « 4UERBÉH » et « 6UERBÉH » une seconde fois, affichant les mots en hébreu de gauche à droite au lieu de les afficher de droite à gauche.
La solution dans ce cas consiste à inactiver l'algorithme bi-directionnel en plaçant l'extrait de message dans un élément PRE (pour conserver les sauts de ligne) et chaque ligne dans un élément BDO dont l'attribut dir a la valeur "LTR" :
<PRE> <BDO dir="LTR">français1 2UERBÉH français3</BDO> <BDO dir="LTR">4UERBÉH français5 6UERBÉH</BDO> </PRE>
Cette disposition dit à l'algorithme bi-directionnel : « Laisse-moi le gauche-à-droite ! », et produirait la représentation désirée,
français1 2UERBÉH français3 4UERBÉH français5 6UERBÉH
L'élément BDO devrait s'utiliser dans les cas de figure où un contrôle absolu sur l'ordre des séquences est nécessaire (par exemple, des numéros de pièces de rechange dans plusieurs langues). L'attribut dir est obligatoire pour cet élément.
Les auteurs peuvent aussi utiliser des caractères spéciaux Unicode pour inactiver l'algorithme bi-directionnel -- « FORÇAGE GAUCHE-À-DROITE » ("LRO", code 202D en hexadécimal) ou « FORÇAGE DROITE-À-GAUCHE » ("RLO", code 202E en hexadécimal). Le caractère de « DÉPILEMENT DE FORMATAGE DIRECTIONNEL » (POP, code 202C en hexadécimal) termine l'un et l'autre forçage bi-directionnel.
Remarque : Se souvenir que des conflits peuvent survenir si l'attribut dir est utilisé sur un élément en-ligne (y compris l'élément BDO) en même temps que sont utilisés les caractères de formatage [UNICODE] correspondants.
La bi-directionnalité et l'encodage des caractères. Selon les documents [RFC1555] et [RFC1556], il existe des conventions particulières pour l'utilisation des valeurs du paramètre « charset », pour indiquer le traitement bi-directionnel à appliquer dans un courrier au format MIME, notamment pour faire une distinction entre les directionnalités visuelle, implicite et explicite. La valeur "ISO-8859-8" (pour l'hébreu) désigne un encodage visuel, la valeur "ISO-8859-8-i" désigne une bi-directionnalité implicite, et "ISO-8859-8-e" une directionnalité explicite.
Comme HTML utilise l'algorithme bi-directionnel Unicode, les documents conformes utilisant l'encodage ISO 8859-8 doivent être étiquetés "ISO-8859-8-i". Un contrôle directionnel explicite est aussi possible avec HTML, mais il ne peut pas être exprimé avec l'encodage ISO 8859-8 et l'étiquette "ISO-8859-8-e" ne devrait donc pas être employée.
La valeur "ISO-8859-8" sous-entend que le document a une mise en forme visuelle, en détournant l'utilisation de certains balisages (tel qu'un élément TABLE avec un alignement à droite et sans saut de ligne) pour assurer un affichage convenable avec les agents utilisateurs plus anciens qui ne gèrent pas la bi-directionnalité. De tels documents ne sont pas conformes à la spécification présente. Au besoin, on peut les rendre conformes à la spécification actuelle (et ils s'afficheront correctement pour les agents utilisateurs plus anciens) en ajoutant la balise BDO, là où c'est nécessaire. Contrairement à ce qui est dit dans les documents [RFC1555] et [RFC1556], l'encodage ISO-8859-6 (pour l'arabe) n'est pas un agencement visuel.
Étant donné que des ambiguïtés surviennent parfois, à propos de la directionnalité de certains caractères (par exemple la ponctuation), la spécification [UNICODE] comprend des caractères qui permettent leur résolution correcte. Unicode comprend également des caractères pour contrôler la conduite des ligatures quand cela est nécessaire (par exemple, dans certaines situations mettant en jeu des lettres arabes). HTML 4 inclut des références de caractères pour les appeler.
L'extrait de DTD suivant présente quelques-unes des entités directionnelles :
<!ENTITY zwnj CDATA "‌"-- = anti-liant sans chasse --> <!ENTITY zwj CDATA "‍"-- = liant sans chasse --> <!ENTITY lrm CDATA "‎"-- = marque de gauche à droite --> <!ENTITY rlm CDATA "‏"-- = marque de droite à gauche -->
L'entité « zwnj » [ndt. zero width non-joiner] s'utilise pour empêcher le comportement de ligature dans les contextes où une ligature aura lieu mais ne le devrait pas. L'entité « zwj » [ndt. zero width joiner] fait le contraire ; elle force la ligature là où elle ne se produirait pas mais le devrait. Par exemple, la lettre arabe « HÉ » s'utilise pour abréger « Hijri », le nom du calendrier islamique. Étant donné que la forme isolée de « HÉ » ressemble au chiffre cinq tel qu'il est employé dans l'écriture arabe (basée sur les chiffres indo-iraniens), on évite la confusion de « HÉ » avec le chiffre cinq final d'une année en utilisant plutôt la forme initiale de « HÉ ». Il n'existe toutefois pas de contexte qui suit (c'est-à-dire une lettre liée) auquel le « HÉ » puisse se rattacher pour prendre la forme désirée. C'est le caractère « zwj » qui fournit ce contexte.
De la même manière, il y a des cas dans les textes persans où une lettre, qui normalement se lierait à la lettre suivante par une liaison cursive, ne le devrait pas. Le caractère « zwnj » s'utilise à cette occasion pour empêcher la ligature.
Les autres caractères « lrm » [ndt. left-to-right mark] et « rlm » [ndt. right-to-left mark] s'utilisent pour forcer la directionnalité des caractères neutres par rapport à la direction. Par exemple, si des guillemets symétriques « " » se trouvent entre une lettre arabe (droite-à-gauche) et une lettre latine (gauche-à-droite), la direction des guillemets n'est pas claire (introduisent-ils une citation du texte arabe ou bien du texte latin ?). Les caractères « lrm » et « rlm » ont une propriété directionnelle mais n'ont aucune propriété de chasse ni de césure. Veuillez consulter [UNICODE] pour plus de précisions.
Les glyphes de caractères réfléchis. En général, l'algorithme bi-directionnel ne réfléchi pas les glyphes de caractères, et il les laisse inchangés. Certains caractères, telles les parenthèses (voir [UNICODE], tableau 4-7) font exception. Dans les cas où la réflexion est souhaitée, par exemple pour les hiéroglyphes égyptiens, le boustrophédon grec ou certains effets esthétiques, cela devrait se contrôler au moyen de styles.
En général, l'utilisation des feuilles de style pour changer la restitution visuelle d'un élément d'un type bloc vers un type en-ligne, et vice versa, est simple. Néanmoins, comme l'algorithme bi-directionnel repose sur la distinction élément de bloc/élément en-ligne, il faut y faire particulièrement attention lors de la transformation.
Quand un élément en-ligne, qui n'a pas d'attribut dir, est transformé dans le style d'un élément bloc par une feuille de style, il hérite de l'attribut dir de son élément de bloc parent le plus proche pour définir la direction de base du nouveau bloc.
Quand un élément de bloc, qui n'a pas d'attribut dir, est transformé dans le style d'un élément en-ligne par une feuille de style, la représentation résultante devrait être équivalente, en termes de formatage bi-directionnel, à la mise en forme qui aurait été obtenue si on avait ajouté explicitement un attribut dir (ayant la valeur héritée) à l'élément transformé.