1 Introduction
1.1 Qui devrait utiliser ce document
Tous les créateurs de contenus HTML travaillant avec XHTML 1.0, HTML 4.01, XHTML 1.1 et CSS.
Le terme « créateur » est utilisé dans le sens décrit par la spécification HTML 4.01,
c'est-à-dire une personne ou un programme écrivant ou générant des documents HTML.
Ce document aide les développeurs HTML à mettre en place un déploiement international.
La mise en place d'un déploiement international est de la responsabilité des créateurs de contenus, pas seulement des groupes de localisation
et des vendeurs, et elle se justifie dès le début du développement. La non-observation des conseils donnés dans ce documents ou leur relégation
à une phase ultérieure du processus de développement ne feront qu'ajouter des coûts et des problèmes de ressources inutiles ensuite.
Les lecteurs sont censés avoir des compétences dans le développement de pages HTML et XHTML, ce document se limitant
à fournir des conseils liés spécifiquement à l'internationalisation.
1.2 Comment utiliser ce document
Ce document est l'un parmi d'autres concernant les pratiques exemplaires de création de contenu Web utilisant les technologies du W3C.
Si ce sujet constitue une nouveauté, vous lirez peut-être le document de bout en bout, toutefois vous l'utiliserez probablement plus tard
en référence, plongeant dans une section particulière afin d'y trouver comment réaliser une tâche spécifique dans un esprit international.
Chaque recommandation de pratique exemplaire est résumée sommairement. Le texte qui suit donne des conseils sur la façon de
mettre en œuvre la pratique exemplaire et fournit d'autres explications si besoin. Dans quelques cas, l'applicabilité de la recommandation
peut varier en fonction des objectifs et du contexte. Lorsqu'une recommandation donnée présente des pour et des contre,
nous essayons de l'indiquer clairement.
On pointe vers des ressources supplémentaires à la fin de chaque pratique exemplaire. Pour vérifier si de nouvelles ressources
sont disponibles depuis la publication de ce document, suivez les liens à la fin de la section des ressources vers les index
techniques et thématiques disponibles dans la section Internationalization du site du W3C.
1.2.1 Notes spécifiques à propos des agents utilisateurs
Dans la version courante de ce document, les agents utilisateurs (user agents) désignent un certain nombre
de navigateurs principaux. (Le champ peut croître au fur et à mesure de la disponibilité de ressources et de résultats de tests
pour d'autres agents utilisateurs).
S'il y a des choses à connaître sur la façon dont un agent utilisateur particulier interprète une pratique exemplaire,
nous essayons de le préciser.
Les petites images après la déclaration initiale de la pratique exemplaire indiquent s'il y a des notes à lire. Les notes en question
apparaissent dans le texte descriptif.
Voici les agents utilisateurs testés pour le document courant, leurs versions et les images utilisées :
Internet Explorer 7 
Internet Explorer 6 
Firefox 2.0 
Opera 9.0 
Netscape Navigator 8.1 
Safari 2.0 
On fournit parfois des renseignements détaillés à propos du comportement d'un agent utilisateur dans une autre version que celle de base
ou celles courantes.
1.3 Les technologies abordées
Ce document décrit des pratiques exemplaires pour développer des pages utilisant HTML 4.01, XHTML 1.0
et XHTML 1.1 avec CSS.
On peut servir du XHTML 1.0 comme XML (en utilisant les types MIME
application/xhtml+xml, application/xml ou text/xml)
ou comme HTML (en utilisant le type MIME text/html). Le XHTML 1.0
est très souvent servi comme du HTML, avec un peu de chance en suivant les
conseils de compatibilité dans l'annexe C de la spécification XHTML 1.0.
Cela permet aux créateurs de produire du code XML valide, qui présente des avantages pour le traitement avec des scripts ou
XSLT, mais aussi qui est bien géré en affichage par la plupart des navigateurs principaux. (Contrairement à du
XHTML servi comme type application/xhtml+xml, qui est pour l'instant mal géré par certains navigateurs).
Dans ce document, pour refléter la réalité pratique des créateurs de contenus, nous couvrons donc le XHTML servi
comme text/html. Tous les exemples (sauf point spécifique à propos de HTML 4.01) sont écrits
en XHTML 1.0.
Pour du XHTML servi comme XML, ce document restreint ses conseils aux documents XHTML 1.1
servis comme application/xhtml+xml.
Lorsqu'un navigateur est susceptible de fonctionner en mode standard ou en mode « bizarreries »
(quirks-mode), on supposera le mode standard (c'est-à-dire qu'on utilisera une déclaration DOCTYPE).
2 Pourquoi lire ce document ?
Il existe déjà des applications capables d'utiliser l'information de langage naturel
(c'est-à-dire le langage humain non informatique) du contenu pour livrer aux utilisateurs les informations ou le style les plus pertinents,
en fonction de leurs préférences de langue. Plus le contenu est étiqueté, et correctement, plus ces applications seront utiles et omniprésentes.
L'information de langue est profitable pour les outils de création, les outils de traduction,
l'accessibilité, la sélection de fontes, le rendu des pages, l'exploration (search)
et les scripts.
En revanche, ces applications ne peuvent pas fonctionner si l'information de langue du texte n'est pas disponible. De fait,
l'information de langue devrait être indiquée pour la page dans son ensemble, et à chaque changement de langue dans la page.
Dans le futur, poussées par les développements technologiques, il y aura d'autres applications pour l'information de langue. Par exemple,
les mises en œuvre du pseudo-élément CSS3 :first-letter auront besoin de l'information de langue
pour une bonne application du style. Quoiqu'il en soit, nous sommes face à un dilemme.
Les personnes qui ne voient pas l'information de langue exploitée ne la fournissent pas pour leurs contenus,
et le déploiement des applications liées aux langues traîne tant que cette information n'est pas répandue.
En général, c'est très facile à faire et ça ne coûte rien.
3 Les concepts importants
3.1 La langue du public visé
Les métadonnées qui décrivent la langue du public visé concernent le document dans son ensemble. Ces métadonnées
peuvent être utilisées pour effectuer une recherche, servir une version dans la bonne langue, classer, etc. Lorsqu'il y a des changements
de langues dans un document, l'information pour la langue du public visé n'est pas assez spécifique, par exemple, pour permettre le
traitement de texte nécessaire pour l'application d'une synthèse vocale
(text-to-speech), d'un style, d'une affectation de fonte automatique (automatic font assignment), etc.
La langue du public visé ne comprend pas toutes les langues utilisées dans le document. Beaucoup de documents du Web incorporent des
fragments de contenu dans des langues différentes alors que la page est clairement destinée aux locuteurs d'une langue particulière.
Par exemple, un guide urbain allemand de Pékin peut contenir des expressions utiles en chinois tout en s'adressant à un public germanophone, et non à un public sinophone.
D'un autre côté, on peut aussi imaginer une situation où un document contient le même contenu ou un contenu parallèle en plusieurs langues.
Par exemple, une page Web peut accueillir des lecteurs canadiens avec un contenu en français dans une colonne à gauche et le même contenu
en anglais dans une colonne à droite. Ici le document vise à égalité les locuteurs des deux langues, il y a donc deux
publics visés. Cette situation n'est pas aussi courante pour le Web que pour les documents imprimés, car il est facile sur le Web de lier
à des pages séparées pour des publics différents, mais le cas se présente avec des communautés plurilingues. Un autre cas d'utilisation
est celui d'un blogue ou d'une page de nouvelles destinés à une communauté plurilingue, où certains articles sur une page sont dans une langue
et d'autres articles dans une autre.
Il y a également les pages où les informations de navigation, y compris le titre de la page, sont dans une langue mais le vrai contenu
de la page dans une autre. Bien que ce ne soit pas nécessairement une pratique exemplaire, cela ne change pas le fait que la langue
du public visé est habituellement celle du contenu, indépendamment de la langue en haut de la source du document.
Il est préférable de déclarer les métadonnées à propos de la langue du public visé hors du document
dans l'en-tête HTTP Content-Language, quoiqu'une déclaration interne avec
l'élément meta soit parfois appropriée.
3.2 La langue de traitement de texte
En indiquant la langue de traitement de texte (text-processing language),
on déclare la langue dans laquelle est en fait écrite une étendue spécifique de texte, afin que les agents utilisateurs ou
les applications qui manipulent le texte, tels que les navigateurs vocaux (voice browsers), les correcteurs orthographiques
(spell checkers) ou les processeurs de style, puissent réellement traiter le texte en question. Nous parlons donc,
nécessairement, d'associer une seule langue à une étendue spécifique de texte.
Cette spécificité distingue la déclaration de la langue de traitement de texte de la langue du public visé.
La langue de traitement de texte se déclare généralement mieux en utilisant des attributs sur les éléments, y compris
l'élément html qui englobe tout le contenu du document. Les éléments englobés héritent de la valeur déclarée,
mais on peut bien sûr écraser (override) une déclaration initiale en définissant une langue différente pour les
éléments incorporés où la langue change, par exemple, un mot en français dans un paragraphe en anglais
(cf. la section « 5 L'utilisation d'attributs pour déclarer la langue »).
3.3 Les relations entre la langue, le codage des caractères et la directionnalité
En HTML et XHTML, les déclarations de langues ne doivent pas et ne devraient pas fournir d'informations
à propos du codage des caractères ou de la direction du texte.
Il existe des mécanismes séparés pour déclarer le codage des caractères et la directionnalité dans HTML et XHTML,
et il ne faudrait pas les confondre avec les mécanismes de déclaration de langues.
Le codage des caractères se rapporte aux séquences d'octets utilisées pour représenter les caractères
dans le texte. Il est important de déclarer quel codage est utilisé pour son document, mais c'est une question distincte que celle de
la déclaration de la langue. (Pour une meilleure compréhension des déclarations de codages de caractères,
cf. le tutoriel « Les jeux de caractères et les codages dans XHTML, HTML et CSS »).
Certaines personnes pensent que l'information de langue peut se déduire du codage de caractères, mais ce n'est pas vrai. Il faudrait
qu'il y ait injection (one-to-one mapping) entre le codage et la langue pour que cela fonctionne, et ce n'est pas le cas.
Un seul codage de caractères tel que ISO 8859-1 (Latin1) pourrait coder le français et l'anglais, ainsi que beaucoup d'autres langues.
En outre, on peut utiliser des codages de caractères différentes pour une seule langue, par exemple, on pourrait coder l'arabe avec
"Windows-1256" ou "ISO 8859-6" ou "UTF-8".
La direction du texte est une autre chose à ne pas confondre avec la langue. Dans certaines écritures,
tels que l'arabe et l'hébreu, le texte affiché se lit majoritairement de droite à gauche, bien que dans ce flux les nombres et le texte
d'autres écritures s'affichent de gauche à droite. Il faut un balisage pour établir le contexte droite-à-gauche global et, dans certaines
circonstances, il faut un balisage pour rendre correctement du texte bidirectionnel, mais on ne peut pas le faire à l'aide d'un
balisage de langue. (Pour une meilleure compréhension de la direction et du balisage du texte,
cf. le tutoriel « La création de pages (X)HTML en arabe et en hébreu »).
Comme pour les codages et la langue, il n'y a pas toujours injection entre la langue et l'écriture, et donc la directionnalité.
Par exemple, on peut écrire l'azéri (ou azerbaïdjanais) en utilisant à la fois des écritures de droite-à-gauche et de gauche-à-droite,
et le code de langue az est pertinent pour les deux. En outre, le balisage de direction du texte utilisé
avec du texte en-ligne (inline text) applique une gamme de valeurs différentes au texte,
tandis que la langue est un simple interrupteur qui n'est pas à la hauteur des tâches requises.
Une pratique exemplaire supplémentaire, reliée depuis la section
Internationalization du site du W3C, décrit comment déclarer le codage des caractères et la direction du texte.
5 L'utilisation d'attributs pour déclarer la langue
Toujours déclarer la langue par défaut du texte dans la page avec les attributs sur la balise html,
sauf si le document offre un contenu destiné à des locuteurs de plusieurs langues.
Aucun problème d'applicabilité avec les agents utilisateurs.
Comment faire : Utilisez les attributs lang et/ou
xml:lang sur la balise html.
L'exemple n° 7 déclare un document HTML en français canadien :
Pour des précisions sur quel attribut de langue utiliser, cf. la
« Pratique exemplaire n° 5 : Choisir entre lang et xml:lang ».
Pour des précisions sur la façon d'indiquer les valeurs de langues, cf. la section
« 7 Le choix des valeurs de langues ».
Discussion : La déclaration de la langue de traitement de texte par défaut
est déjà importante pour des applications telles que l'accessibilité
et l'exploration (searching), mais cette information pourra faire l'objet de
beaucoup d'autres applications possibles avec le temps.
La déclaration de la langue de traitement de texte dans la balise html établit la langue par défaut
du document entier. Au besoin, elle peut être écrasée pour des parties du document. Pour cette raison, on devrait toujours essayer
de déclarer une langue dans la balise html. C'est généralement très facile à faire à la création du document,
mais beaucoup moins plus tard pour tirer profit des caractéristiques linguistiques.
La plupart des documents proposent un contenu destiné à des locuteurs monolingues, mais lorsqu'on sait que le public visé lira
un contenu en plusieurs langues (par exemple, un blog plurilingue ou une page destinée à plusieurs communautés de langues), il est concevable
de déclarer la langue de traitement de texte par défaut dans la suite du document plutôt que dans la balise html.
La meilleure approche dépendra de la structure employée pour le document. Cf. la
« Pratique exemplaire n° 2 : Utiliser les attributs dans la balise html pour les publics plurilingues ».
Pour un document avec un contenu destiné à des locuteurs de plusieurs langues, décidez si vous voulez déclarer une
seule langue dans la balise html ou bien définir les langues plus tard.
Aucun problème d'applicabilité avec les agents utilisateurs.
Comment faire : L'exemple n° 8
montre un document simple avec un contenu destiné à des publics plurilingues. Ici le document est divisé en deux tout de suite après
l'élément body, et l'auteur a retardé jusque là la déclaration de la langue de traitement de texte.
<html xmlns= "http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title>Welcome - Bienvenue</title>
</head>
<body>
<div lang="en" xml:lang="en">
<h1>Welcome!</h1>
<p>Lots of text in English...</p>
</div>
<div lang="fr" xml:lang="fr">
<h1>Bienvenue !</h1>
<p>Beaucoup de texte en français...</p>
</div>
</body>
</html>
Remarque : Les éléments title plurilingues posent des problèmes.
On ne peut déclarer qu'une seule langue pour cet élément dans HTML 4.01, car seules sont admises des données textuelles
(character data). Il n'existe actuellement aucune solution adéquate à ce problème. Dans XHTML 2.0,
il ne devrait plus se poser.
Pour des précisions sur quel attribut de langue utiliser, cf. la
« Pratique exemplaire n° 5 : Choisir entre lang et xml:lang ».
Pour des précisions sur la façon d'indiquer les valeurs de langues, cf. la section
« 7 Le choix des valeurs de langues ».
Discussion : Cf. la définition de la langue du public visé.
Les documents avec un contenu destiné à des publics de plusieurs langues sont rares. Un document n'est pas destiné à un public plurilingue
s'il contient des petites quantités de textes en d'autres langues. Nous parlons ici des langues parlées par les publics visés.
Bien que nous recommanderions normalement de déclarer la langue de traitement de texte par défaut
dans la balise html, puisqu'on ne peut définir qu'une seule langue à la fois avec les attributs,
il peut sembler sans intérêt de le faire si le document a un contenu distinct pour soutenir des publics plurilingues. Il est peut-être
plus approprié de commencer l'étiquetage de la langue sur les éléments de niveau inférieur, où se trouve concrètement le texte
dans une langue ou dans une autre.
Si toutefois l'information d'en-tête ou la navigation de la page sont dans une langue particulière, ou s'il existe en quelque sorte
un parti pris envers une langue particulière dans la première partie du document, on peut toujours utiliser un attribut de langue
sur la balise html puis passer outre (override)
dans les éléments appropriés de niveau inférieur.
Lorsque le contenu d'un document est destiné à des locuteurs de plusieurs langues, essayez de découper linguistiquement
le document au niveau le plus élevé possible et déclarez la langue appropriée pour chaque découpage.
Aucun problème d'applicabilité avec les agents utilisateurs.
Le découpage du contenu en plusieurs langues au niveau le plus élevé possible peut simplifier le processus
de guider les utilisateurs vers le texte via une recherche (searching), des liens, etc. Il réduit également le
travail d'étiquetage de la langue des fragments de document.
Pour des précisions sur la façon d'utiliser les attributs de langues, cf. la section
« 7 Le choix des valeurs de langues ».
Utilisez les attributs lang et/ou xml:lang autour du texte
pour indiquer les changements de langues.
Aucun problème d'applicabilité avec les agents utilisateurs.
Comment faire : Lorsque la langue du texte diffère de celle déclarée dans la
balise html, l'indiquer en utilisant les attributs
lang
et/ou xml:lang. Par exemple, dans HTML,
on écrirait :
<p>The French for <em>Cat</em> is <em lang="fr">chat</em>.</p>
On peut utiliser l'attribut lang sur tous les éléments HTML sauf applet,
base, basefont, br, frame,
frameset, iframe, param et script.
(En passant, notez qu'on pourrait utiliser les attributs de langue sur des objets tels que des fichiers image en mode point
(bitmaps) ou son (audio), spécifiques d'une langue. Une telle information peut être particulièrement utile pour le
traitement des documents par des scripts).
S'il n'y a aucun balisage autour du texte de langue différente, utilisez un élément span afin d'en marquer
les limites. Voici un exemple en XHTML 1.0 servi comme type text/html :
<p>The title in Chinese is <span lang="zh-Hans" xml:lang="zh-Hans">中国科学院文献情报中心</span>.</p>
Pour des précisions sur quel attribut de langue utiliser, cf. la
« Pratique exemplaire n° 5 : Choisir entre lang et xml:lang ».
Pour des précisions sur la façon d'indiquer les valeurs de langues, cf. la section
« 7 Le choix des valeurs de langues ».
Pour
HTML, utilisez l'attribut
lang seul, pour
XHTML 1.0
servi comme type
text/html, utilisez les attributs
lang et
xml:lang
et pour
XHTML servi comme du
XML, utilisez uniquement l'attribut
xml:lang.
Aucun problème d'applicabilité avec les agents utilisateurs.
Comment faire : Pour un service HTML, utilisez
l'attribut lang. Par exemple, voici un document
déclaré en français canadien :
Pour un service XHTML comme type text/html, utilisez les deux attributs lang
et xml:lang.
L'exemple n° 12 montre comment marquer un document XHTML 1.0
servi avec le type text/html.
<html lang="fr-CA" xml:lang="fr-CA" xmlns ="http://www.w3.org/1999/xhtml">
Pour le service de pages XHTML de type XML (c'est-à-dire avec un type MIME
tel que application/xhtml+xml), par exemple le service de pages XHTML 1.1, utilisez uniquement
l'attribut xml:lang (cf. l'exemple n° 13).
<html xml:lang="fr-CA" xmlns ="http://www.w3.org/1999/xhtml">
Discussion : L'attribut xml:lang est la méthode normale pour identifier une
information de langue dans XML, mais le navigateur reconnaît seulement l'attribut lang
si la page est servi avec le type text/html. Au contraire, pour un traitement du document en tant que XML,
l'attribut xml:lang aura toute son utilité. Puisque XHTML 1.0 peut être utilisé
dans les deux contextes HTML et XML, on devrait employer les deux attributs.
L'attribut lang entraînera l'échec de la validation des pages XHTML 1.1,
car il a été supprimé de la définition de ce langage.
Utilisez les attributs de langue plutôt que
HTTP ou les éléments
meta pour déclarer la
langue de traitement de texte par défaut.
Aucun problème d'applicabilité avec les agents utilisateurs.
Ne déclarez pas la langue par défaut du document dans l'élément body,
utilisez l'élément html.
Aucun problème d'applicabilité avec les agents utilisateurs.
Comment faire : Utilisez les attributs lang et/ou
xml:lang sur la balise html.
L'exemple n° 15 déclare un document HTML en français canadien :
Discussion : L'élément html est celui de plus haut niveau dans le document, et il est donc
plus approprié pour déclarer la langue de traitement de texte par défaut du document.
Tous les éléments dans le document hériteront de cette valeur.
La balise body n'est normalement pas le meilleur endroit pour exprimer cette information car celle-ci
ne se rapporte qu'à une partie du texte du document. Par exemple, le texte dans l'élément title
est du texte en langue naturelle qui devrait également hériter de l'information de langue. Si la langue est déclarée dans
l'élément body, ce ne sera pas le cas.
La seule situation où cela pourrait avoir un sens est lorsque les contenus des éléments head et body sont
dans des langues différentes.
Si le texte dans les valeurs d'attributs et le contenu de l'élément sont dans des langues différentes, alors envisagez
d'utiliser une approche imbriquée.
Aucun problème d'applicabilité avec les agents utilisateurs.
Problème : On peut rencontrer une situation où les langues du texte dans un attribut et
dans le contenu de l'élément sont dans des langues différentes. Par exemple, dans le coin supérieur droit de chaque page de la section
Internationalization du site du W3C, on trouve des liens vers les versions traduites de la page en question
(cf. la figure n° 1). Le nom de la langue est donné dans la langue de la page cible,
mais l'attribut title contient le nom dans la langue de la page courante :
Si on crée le code comme dans l'exemple n° 16 ci-dessous, les attributs de langue
indiqueraient en fait que non seulement le contenu mais aussi le texte de l'attribut title sont en suédois.
Ce qui est bien sûr inexact.
<p><a xml:lang="sv" lang="sv" title="Swedish" href="index.sv.html">svenska</a></p>
Comment faire : Déplacez l'attribut contenant le texte dans une langue différente dans un autre élément, comme dans cet
exemple, où la balise p hérite du paramétrage par défaut "en" de la balise html.
<p title="Swedish"><a xml:lang="sv" lang="sv" href="index.sv.html">svenska</a></p>
Le balisage dans l'exemple n° 17 se prête aisément à cette approche.
Dans d'autres cas, on peut avoir besoin d'un élément span pour porter l'attribut title.
Pour des précisions sur quel attribut de langue utiliser, cf. la
« Pratique exemplaire n° 5 : Choisir entre lang et xml:lang ».
Pour des précisions sur la façon d'indiquer les valeurs de langues, cf. la section
« 7 Le choix des valeurs de langues ».
6 La déclaration de métadonnées pour la langue du public visé
Envisagez d'utiliser une déclaration
Content-Language dans l'en-tête
HTTP ou une
balise
meta pour déclarer les métadonnées pour la langue (ou les langues) du public visé d'un document.
Aucun problème d'applicabilité avec les agents utilisateurs.
Comment faire : L'information Content-Language envoyée dans l'en-tête HTTP
est définie sur le serveur. La méthode pour la paramétrer est spécifique du serveur et elle n'est pas abordée ici.
Autrement, on peut ajouter une déclaration Content-Language dans un élément meta
dans l'en-tête du document, comme illustré dans l'exemple n° 18).
<meta http-equiv="Content-Language" content="en"/>
Discussion : La déclaration Content-Language, qu'elle ait lieu dans l'en-tête HTTP ou
dans une balise meta de type Content-Language, peut servir à exprimer des métadonnées
pour la langue (ou les langues) du public visé du document servi.
À ce niveau, on ne sait pas trop dans quelle mesure les applications utilisent les informations de métadonnées dans l'en-tête HTTP
ou dans la balise meta, ou laquelle des deux elles préfèrent.
L'utilisation de Content-Language dans l'en-tête HTTP entraîne des problèmes potentiels
liés à l'entretien et l'utilisation de l'information côté serveur. Beaucoup d'auteurs auront du mal à accéder au paramétrage du serverur,
en particulier s'ils traitent avec un fournisseur de services Internet. Également, les pages ne se trouvent pas forcément sur des serveurs.
Cette approche ne constitue donc pas une solution toujours disponible.
Parfois, le serveur est réglé pour servir automatiquement la version d'une ressource spécifique d'une langue en fonction du paramétrage
du navigateur de l'utilisateur (négotiation de contenu). Auquel cas, le serveur envoie probablement une information de langue dans
l'en-tête Content-Language.
Pour d'autres explications à ce sujet, cf. les sections
« 3 Les concepts importants » et
4 Les mécanismes de déclaration de langues dans HTML.
Lorsqu'un document a un contenu destiné à des locuteurs de plusieurs langues, utilisez Content-Language
avec une liste de codes de langue séparés par des virgules.
Aucun problème d'applicabilité avec les agents utilisateurs.
Comment faire : L'information Content-Language envoyée dans l'en-tête HTTP
est définie sur le serveur. La spécification HTTP permet l'expression de plusieurs langues en valeur d'en-tête Content-Language.
L'exemple n° 19 montre une partie de l'en-tête HTTP envoyée par
le serveur et déclare un document destiné à des locuteurs de trois langues, à savoir l'allemand, le français et l'italien :
Content-Language: de,fr,it
L'élément meta de type Content-Language dans le document offre une possibilité similaire
(cf. l'exemple n° 20) :
<meta http-equiv="Content-Language" content="de,fr,it"/>
Discussion : Il est rare de trouver une page sur le Web dont le contenu est destiné à un public plurilingue.
Une raison à cela est qu'il est facile de lier à des pages alternatives à la place. D'un autre côté, de telles pages existent.
Un exemple en serait une page de bienvenue en anglais et en français canadien, ou en anglais et en gallois. Un autre type d'exemple serait
une page destinée à un public largement plurilingue, et contenant des nouvelles ou des billets en plusieurs langues (par exemple, en Inde,
où l'anglais et l'hindi sont des langues courantes, mais où les personnes utilisent aussi leur propre langue régionale pour communiquer).
Ressources :
- La définition de
Content-Language dans HTTP/1.1 (section 14.12).
Content-Language
7 Le choix des valeurs de langues
Suivez les directives dans le document
BCP 47 de l'
IETF pour les valeurs d'attributs de langues.
Aucun problème d'applicabilité avec les agents utilisateurs.
Comment faire : Choisissez les sous-étiquettes dans le
registre des sous-étiquettes de langues IANA.
Pour combiner les sous-étiquettes, faites-le conformément à la syntaxe décrite dans le document
BCP 47.
Pour une introduction en douceur au registre et au règles BCP 47 de composition des codes de langues,
cf. l'article « Les étiquettes de langues dans HTML et XML ».
Notez que les attributs lang
et xml:lang ne prennent qu'une seule valeur de langue
(contrairement aux en-têtes HTTP Content-language).
Discussion : Le recueil BCP 47 pointe vers
les documents IETF qui définissent les étiquettes de langues (BCP sont les initiales de
« Best Current Practice »). Lorsque ce document de pratiques exemplaires a été publié,
le lien BCP 47 recensait les documents RFC 4646 : Les étiquettes d'identification des langues
et RFC 4647 : La correspondance des étiquettes de langues.
Le premier document décrit la syntaxe des étiquettes de langues. (Cf. l'historique dans la note qui suit).
Utiliser BCP 47 comme référence commune pour définir les étiquettes de langues garantit une large reconnaissance des étiquettes.
Remarque : BCP 47 est le nom générique constant
d'une série de spécifications IETF ultimes appelées normalement des RFC. Chaque nouveau document RFC
a un numéro, habituellement non lié au document RFC qu'il remplace et rend obsolète. La spécification IETF
originale qui décrivait les valeurs des étiquettes de langues était le document RFC 1766.
Il est devenu obsolète avec le document RFC 3066, également premier dénommé
BCP 47. Celui-ci a été remplacé en septembre 2006 par les deux spécifications
RFC 4646 et RFC 4647.
La première décrit la syntaxe des étiquettes de langues et la seconde décrit comment assortir (match) les étiquettes.
Le registre des sous-étiquettes IANA associé
était déjà en vigueur depuis quelques mois quand ces spécifications reçurent leurs numéros IETF.
Le document RFC 4646 ne fait que développer et clarifier les possibilités d'indication des langues. Si vous utilisiez les documents
RFC 1766 ou RFC 3066, il est inutile de changer votre code pour commencer à utiliser RFC 4646. Les documents successeurs de RFC 4646
retiendront également la rétrocompatibilité avec les étiquettes créées en utilisant RFC 4646.
La spécification HTML recommande toujours d'utiliser le document RFC 1766 pour identifier la langue. Quoiqu'il en soit,
une correction de la spécification HTML est prévue, donc contrairement à ce que dit actuellement la spécification HTML,
vous devrez utiliser RFC 4646 ou ses successeurs dès qu'elle sera publiée.
Utilisez les valeurs d'étiquette de langue les plus courtes.
Aucun problème d'applicabilité avec les agents utilisateurs.
Comment faire : Lorsqu'on crée des étiquettes de langues, la règle d'or est de garder l'étiquette
aussi courte que possible. Éviter la région, l'écriture ou autres sous-étiquettes sauf si elles ajoutent une information distinctive utile.
Par exemple, utilisez ja pour le japonais et non ja-JP, à moins d'avoir une raison particulière d'indiquer
qu'il s'agit du japonais parlé spécifiquement au Japon.
De même, n'utilisez pas d'écriture ou de variantes de codes sauf si nécessaire pour distinguer correctement votre contenu d'autre chose.
Bien que le document RFC 4646 introduise des étiquettes d'écritures (script tags), comme l'écrit un des co-auteurs :
« Pour pratiquement tout contenu n'utilisant pas d'étiquette d'écriture aujourd'hui, la meilleure pratique reste de ne pas en utiliser
dans le futur ».
Dans le passé, les gens se demandaient quel code de langue ISO choisir, puisque il y a souvent des alternatives en deux lettres
et en trois lettres (et parfois deux alternatives en trois lettres) pour la même langue. Bien que les règles fussent claires à ce sujet
dans le document RFC 3066, cette question est désormais contestable car on devrait seulement utiliser les étiquettes de langues définies dans
le registre des sous-étiquettes de langues IANA,
et il n'y existe qu'une seule sous-étiquette par langue (la plus courte).
Lorsque c'est possible, utilisez les codes zh-Hans ou zh-Hant
pour désigner respectivement le chinois simplifié ou le chinois traditionnel.
Problèmes d'applicabilité avec les agents utilisateurs pour :
Comment faire : Utilisez respectivement zh-Hans
et zh-Hant pour le chinois simplifié et le chinois traditionnel dans les valeurs d'attributs de langue,
éventuellement aussi pour les valeurs de Content-Language. Ces codes proviennent
du registre des sous-étiquettes de langues IANA.
<p lang="zh-Hans" xml:lang="zh-Hans">当世界需要沟通时，请用统一码！</p>
<p lang="zh-Hant" xml:lang="zh-Hant">當世界需要溝通時，請用統一碼!</p>
Discussion : Le chinois simplifié et le chinois traditionnel se distinguent par leur écriture. Jusqu'à récemment,
il n'y avait aucune disposition quant à l'utilisation d'une information d'écriture dans les étiquettes de langues, et donc on utilisait
couramment zh-CN (chinois parlé en Chine contientale) pour qualifier l'écriture chinoise simplifiée,
et zh-TW (chinois parlé à Taïwan) pour l'écriture chinoise traditionnelle. Hormis le mauvais étiquetage, on ne pouvait pas
garantir que d'autres reconnaissent ces conventions, ou même les suivent. Par exemple, certains utilisaient « zh-HK » pour représenter
le chinois traditionnel.
On devrait commencer à utiliser les nouvelles étiquettes aussitôt que possible afin d'asseoir rapidement une bonne interopérabilité.
Il y a déjà une forte utilisation de ces codes.
D'un autre côté, dans quelques cas, on peut avoir besoin d'évaluer l'impact du changement des étiquettes. Ce n'est pas vraiment un problème
pour une utilisation en auto-description (self-describing usage), tel qu'avec l'attribut :lang
pour l'application d'un style en fonction de la langue. C'est peut-être plus problématique lorsque des applications externes sont à la recherche
d'étiquettes liées au texte chinois sans avoir connaissance des variantes zh-Hans et zh-Hant.
Remarques spécifiques pour les agents utilisateurs : Il existe un domaine particulier où cela peut être un problème
pour l'affichage du texte sur un agent utilisateur. Certains agents utilisateurs se servent de l'information de langue pour sélectionner
automatiquement une fonte pour du texte idéographique CJK. Cependant, notez que cela suppose
la vérification des conditions suivantes :
Que vous ayez paramétré les fontes appropriées dans vos préférences,
Que le style du document n'indique pas de fonte, et
Que l'agent utilisateur applique ce comportement (ce n'est pas le cas général).
C'est donc un scénario d'utilisation assez limité.
Voici un résumé de la gestion de cette fonction dans les agents utilisateurs testés pour ce document
au moment de la rédaction. Cf. la page de résultats des tests
pour des précisions et les derniers constats.
Safari ne gère pas cette assignation de fonte automatique. Firefox, Mozilla, Netscape, Opera et IE7 traitent les valeurs zh-Hans et zh-Hant
comme prévu. Par contre, IE6 applique la fonte par défaut, qui est la japonaise.
Notez que Firefox, Mozilla et Netscape permettent également un paramétrage différent pour les chinois traditionnels de Taïwan et de Hong Kong.
Ceux-ci utilisent la fonte taïwanaise pour les valeurs zh-Hans et zh-TW, et le paramétrage de fonte de Hong Kong pour zh-HK.
8 L'indication de la langue de la destination d'un lien
Lorsque le lien pointe vers une ressource dans une autre langue, soupesez le pour et le contre
d'indiquer la langue du document cible.
Aucun problème d'applicabilité avec les agents utilisateurs.
Pour : Peut aider le lecteur à ne pas perdre son temps à visiter des pages qu'il ne peut pas lire.
Contre : Peut se périmer et donc donner des informations inexactes.
Discussion : Si on ajoute du texte ou une image à un lien pour indiquer que le document cible est dans une autre langue,
cela permettra peut-être au lecteur de décider à l'avance de suivre ou non le lien, en fonction de ses compétences linguistiques.
Si le lecteur suit le lien pour seulement constater qu'il ne peut pas lire le document cible, il perd son temps, cela le frustre,
et il peut éventuellement se méfier de liens menant en fait à des pages lisibles.
Par contre, cette approche recèle des problèmes potentiels si paraît une nouvelle version traduite du document cible.
Supposons, par exemple, qu'une page en français ait utilisé cette approche dans le passé pour pointer vers un deuxième document uniquement
disponible en anglais à ce moment. Plus tard, le deuxième document est traduit en français et une négociation de contenu mise en place.
À moins de mettre à jour la première page en français, celle-ci informera désormais les lecteurs français, faussement, que le
deuxième document est en anglais, les décourageant probablement de suivre un lien menant en réalité à un document parfaitement lisible.
Si vous voulez indiquer que le document cible d'un élément
a est dans une autre langue,
examinez le pour et le contre d'utiliser
hreflang avec des feuilles de style
CSS.
Problèmes d'applicabilité avec les agents utilisateurs pour :
Pour : Peut aider le lecteur à ne pas perdre son temps à visiter des pages qu'il ne peut pas lire ;
épargne du temps et des efforts à l'auteur si l'attribut hreflang est utilisé logiquement.
Contre : Peut se périmer et ainsi donner une information inexacte ; les agents utilisateurs ne gèrent pas tous
les feuilles de style CSS nécessaires ; problématique pour la liaison vers des sites avec négociation de langue.
Comment faire : Cette approche repose sur des sélecteurs CSS qui détectent la valeur de
l'attribut hreflang et utilisent la propriété CSS content pour afficher une
indication de la langue.
Par exemple, le lien suivant pointe vers une page en suédois.
Le balisage du paragraphe est le suivant :
<p>Il y a égalemnt une page décrivant <a href="swedish-doc.html" hreflang="sv">pourquoi une déclaration DOCTYPE est utile</a>.</p>
Le code CSS d'activation est peut-être quelque chose comme :
a[hreflang]:after { content: " [" attr(hreflang) "] "; }
Cela signifie : « Pour chaque élément a avec un attribut hreflang,
ajouter la valeur de cet attribut entre des crochets après le lien ».
On pourrait tout aussi aisément ajouter du texte, ou même une image, après le lien en l'associant à la propriété content,
au lieu de attr(hreflang). C'est peut-être mieux si on n'est pas sûr que les lecteurs reconnaîtront les
abréviations ISO.
Cette fois-ci, on pourrait utiliser le code CSS suivant. Il le faut pour chaque document cible dans une langue différente.
a[hreflang = 'sv']:after { content: " [en suédois] "; }
Cela signifie : « Pour chaque élément a avec un attribut hreflang dont la
valeur est "sv", ajoutez la valeur de la propriété content après le lien ».
Le balisage reste le même. Le résultat affiché serait :
Discussion : Dans HTML, l'attribut hreflang d'un élément a
indique la langue du document à l'autre bout du lien. En pratique, l'information hreflang
n'est généralement pas relevée par les navigateurs principaux. Par ailleurs, il vaut mieux s'assurer que le document cible utilise
l'attribut de langue dans la balise html, de sorte que cette information ne soit pas nécessaire.
Il est peut-être (un peu) plus courant d'utiliser cet attribut pour générer une marque visible jointe au texte du lien afin d'indiquer
la langue de la page de destination au lecteur. L'idée est de laisser le lecteur décider à l'avance s'il doit suivre ou non le lien,
en fonction de ses compétences linguistiques.
Cette approche recèle des pour et des contre en ce qui concerne l'utilisabilité (usability), qui sont abordés dans
la Pratique exemplaire n° 14 : Identifier la langue d'un document cible.
Il y a aussi des problèmes techniques potentiels avec cette approche en utilisant Internet Explorer (cf. ci-dessous). Le fait
qu'Internet Explorer ne la gère pas est important, vu sa part de marché. En revanche, cela ne ruine pas la page sur IE.
L'utilisateur ne voit tout simplement pas cette information. C'est-à-dire qu'on peut toujours utiliser cette technique,
tant que l'information n'est pas primordiale pour l'utilisateur, ce qui améliorera l'expérience d'utilisateur sur les autres navigateurs.
Notez aussi que, si une ressource est disponible en plusieurs langues via une négociation de contenu côté serveur, l'on ne peut pas
exprimer la gamme de langues exposée, puisque l'attribut hreflang n'accepte qu'une seule langue pour valeur.
Problèmes avec les agents utilisateurs : Voici un résumé de la gestion de cette fonction par les
agents utilisateurs testés pour ce document au moment de la rédaction. Cf. la
page des résultats de tests pour des précisions
et les derniers résultats.
Internet Explorer 6 et 7 ne gèrent ni les sélecteurs :before et :after
ni la propriété content.
L'approche fonctionne bien pour tous les autres agents utilisateurs testés.
Ressources :
- L'attribut
hreflang dans la spécification HTML (section 12.2).
L'élément a
N'utilisez pas d'images de drapeaux pour indiquer les langues.
Aucun problème d'applicabilité avec les agents utilisateurs.
Comment faire : Utilisez du texte. Cf. l'exemple n° 23
pour une illustration.
Discussion : Les drapeaux représentent des pays, non des langues. Beaucoup de pays utilisent la même langue que d'autres,
et beaucoup ont plusieurs langues officielles. Les drapeaux ne correspondent pas à ces permutations.
