Lisez-moi S.V.P. 

[ table des matières ]

W3C

Les pratiques exemplaires d'internationalisation : L'indication de la langue dans les contenus XHTML et HTML

Note de groupe de travail du W3C du 12 avril 2007

Cette version :
http://www.w3.org/TR/2007/NOTE-i18n-html-tech-lang-20070412/
Dernière version :
http://www.w3.org/TR/i18n-html-tech-lang/
Version précédente :
http://www.w3.org/TR/2006/WD-i18n-html-tech-lang-20060721/
Rédacteur :
Richard Ishida, W3C

Résumé

L'indication de la langue d'un contenu se révèle utile pour une large gamme d'applications, de l'analyse linguistiquement sensible jusqu'à l'application de propriétés d'affichage spécifiques des langues. Dans certains cas, les applications potentielles de l'information de langue n'ont pas encore de mises en œuvre, tandis que dans d'autres, telle la détection de la langue par les navigateurs vocaux, c'est une nécessité aujourd'hui. D'un autre côté, on peut ajouter un balisage d'information de langue au contenu et on devrait le faire dès maintenant. Sans cela, on ne pourra pas profiter des développements à venir.

Statut de ce document

Cette section décrit le statut de ce document au moment de sa publication. D'autres documents peuvent le remplacer. On peut trouver une liste des publications actuelles du W3C et la dernière révision de ce rapport technique dans l'index des rapports techniques du W3C à http://www.w3.org/TR/.

Il s'agit d'une note de groupe de travail du W3C produite par le groupe de travail Internationalization Core, partie de l'activité Internationalization du W3C.

Ce document appartient à une série de documents dont l'ambition est de fournir des pratiques exemplaires aux auteurs HTML afin de développer du HTML internationalisé avec XHTML 1.0 ou HTML 4.01, épaulé par CSS1, CSS2 et dans une certaine mesure CSS3. Le document porte spécialement sur des conseils pour indiquer la langue du contenu. Il est produit par le groupe de travail Internationalization Core de l'activité Internationalization du W3C.

Le document décrit des pratiques exemplaires pour indiquer la langue d'un contenu que les créateurs de contenus HTML peuvent utiliser pour adapter aisément leur HTML un public international. Il vaut mieux appliquer ces pratiques exemplaires dès le début du développement du contenu si on veut éviter des coûts et problèmes de ressources inutiles par la suite.

Veuillez adresser les commentaires relatifs à ce document à www-international@w3.org (archives publiques).

La publication en tant que note de groupe de travail n'implique pas une approbation de l'ensemble des adhérents du W3C. C'est une ébauche qui peut, à tout instant, être mise à jour, remplacée ou rendue obsolète par d'autres documents. Il est impropre de citer ce document autrement que comme un travail en cours.

Ce document a été produit par un groupe agissant sous couvert de la politique de brevets du W3C du 5 février 2004. Le W3C tient une liste publique des divulgations de brevets établie en rapport avec les produits livrables du groupe, cette page contient également des intructions pour divulguer un brevet. Toute personne ayant connaissance réelle d'un brevet qu'elle estime contenir des revendications essentielles doit divulguer cette information conformément à la section 6 de la politique de brevets du W3C.

Table des matières

Annexe


Vers la table des matières.1 Introduction

Vers la table des matières.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.

Vers la table des matières.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.

Vers la table des matières.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 icon

  • Internet Explorer 6 Internet Explorer icon

  • Firefox 2.0 Firefox icon

  • Opera 9.0 Opera icon

  • Netscape Navigator 8.1 Netscape icon

  • Safari 2.0 Safari icon

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.

Vers la table des matières.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).

Vers la table des matières.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.

Vers la table des matières.3 Les concepts importants

Vers la table des matières.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.

Vers la table des matières.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 »).

Vers la table des matières.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.

Vers la table des matières.4 Les mécanismes de déclaration de langues dans HTML

Les spécifications HTML et XHTML définissent plusieurs endroits où on peut ou non déclarer la langue. Dans la section 4.1 Les approches possibles, nous montrerons simplement des exemples des options disponibles. Si vous êtes familier avec ça, passez directement à la section 4.2 Quelle approche adopter ?, qui explique quelle méthode utiliser et quand l'utiliser.

Vers la table des matières.4.1 Les approches possibles

Vers la table des matières.4.1.1 Les attributs

La première méthode consiste à utiliser les attributs lang et xml:lang sur un élément XHTML.

Pour établir la langue d'un document entier, on peut utiliser les attributs sur la balise html. Cette valeur sera héritée dans le document entier, à moins d'être écrasée par une déclaration sur un élément contenu.

On peut aussi utiliser les attributs sur des éléments contenant du texte dans une langue différente de celle du contenu environnant.

Exemple n° 1 : Déclarations de langue par attributs dans un document XHTML 1.0 servi comme type text/html.

<html lang="en" xml:lang="en" xmlns= "http://www.w3.org/1999/xhtml">

Vers la table des matières.4.1.2 L'élément meta de type Content-Language

Autrement, on peut trouver des documents qui placent l'information de langue dans un élément meta avec un attribut http-equiv valant "Content-Language".

Exemple n° 2 : Une déclaration de type Content-Language dans un élément meta.

<meta http-equiv="Content-Language" content="en" />

Vers la table des matières.4.1.3 L'élément meta de type Dublin Core

Comme l'élément meta fixe peu de limites à ce qu'on peut dire, il serait aussi possible, quoique peu courant, d'exprimer l'information de langue en utilisant la notation Dublin Core.

Exemple n° 3 : Une déclaration de notation Dublin Core dans un élément meta.

<meta name="dc.language" content="en" />

Vers la table des matières.4.1.4 L'en-tête HTTP

L'information de langue peut aussi se trouver dans l'en-tête HTTP envoyée avec un document (cf. la dernière ligne dans l'exemple d'en-tête HTTP suivant).

Exemple n° 4 : Une en-tête HTTP contenant une déclaration de langue.
HTTP/1.1 200 OK
Date: Wed, 05 Nov 2003 10:46:04 GMT
Server: Apache/1.3.28 (Unix) PHP/4.2.3
Content-Location: CSS2-REC.en.html
Vary: negotiate,accept-language,accept-charset
TCN: choice
P3P: policyref=http://www.w3.org/2001/05/P3P/p3p.xml
Cache-Control: max-age=21600
Expires: Wed, 05 Nov 2003 16:46:04 GMT
Last-Modified: Tue, 12 May 1998 22:18:49 GMT
ETag: "3558cac9;36f99e2b"
Accept-Ranges: bytes
Content-Length: 10734
Connection: close
Content-Type: text/html; charset=iso-8859-1
Content-Language: en

Vers la table des matières.4.1.5 Les lecteurs plurilingues

Notez que l'élément meta avec Content-Language et l'en-tête HTTP autorisent tous deux la fourniture d'une liste de valeurs. L'exemple suivant déclare comme langues du public visé du document (à mesure égale) l'allemand, le français et l'italien.

Exemple n° 5 : Un élément meta avec une valeur de multiples langues.

<meta http-equiv="Content-Language" content="de, fr, it"/>

Vers la table des matières.4.1.6 CSS

Il n'est pas possible d'indiquer la langue du texte dans les déclarations CSS.

Vers la table des matières.4.1.7 Les déclarations DOCTYPE

Certains s'interrogent parfois sur ce qui ressemble à une déclaration de langue dans la déclaration DOCTYPE. Ces déclarations apparaissent au début des fichiers HTML ou XHTML, avant l'élément html. L'exemple n° 6 montre une déclaration DOCTYPE contenant la séquence EN, qui veut dire « English ». Par contre, celle-ci indique la langue du schéma associé au document, et elle n'a rien à voir avec la langue du document même.

Exemple n° 6 : Une déclaration DOCTYPE n'indique pas la langue du document.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Vers la table des matières.4.2 Quelle approche adopter ?

En bref, ce document recommande de toujours déclarer la langue du contenu pour satisfaire aux besoins du traitement de texte. Nous vous recommandons de le faire en utilisant les attributs dans l'élément html (pour établir la langue par défaut de tout le document) et sur tout élément avec un contenu dans une langue différente..

Les déclarations de langues avec attributs sont importantes pour la plupart des applications d'information de langue sur le Web aujourd'hui, de la correction orthographique dans l'éditeur, au style et à la synthèse vocale de la page livrée, etc.

Si vous souhaitez fournir des métadonnées à propos de la langue du public visé pour le document, vous devriez utiliser un ou plusieurs des mécanismes décrits dans la section précédente, c'est-à-dire ne pas utiliser les attributs.

Il reste encore beaucoup d'inconnues autour de l'utilité courante des en-têtes HTTP ou des éléments meta à déclarer la langue du public visé, du fait de l'exploitation trop faible actuellement de cette information. Cela peut changer, surtout si les bibliothèques et utilisateurs similaires se découvrent un intérêt accru pour les métadonnées de langue.

Vers la table des matières.4.2.1 Attributs contre Content-Language : les différences

Les gens sont particulièrement désorientés à propos de la différence entre déclarer la langue du document dans son ensemble en utilisant le champs Content-Language dans l'en-tête HTTP ou dans les éléments meta, et la déclarer en utilisant un attribut sur l'élément html.

Sur le Web, presque tous les conseils non officiels pour déclarer la langue d'un document disent d'utiliser simplement la balise meta. Du moins, un outil de création populaire insère automatiquement l'information de langue, déclarée dans la boîte de dialogue des propriétés de la page, dans un élément meta uniquement. Nous prétendons que, si l'on ne devait faire qu'une chose, ce serait de déclarer la langue pour les besoins du traitement de texte et, pour cela, qu'il faudrait utiliser les attributs, non les autres méthodes.

Les points importants suivants examinent pourquoi les attributs conviennent mieux à la déclaration de la langue de traitement de texte et les autres méthodes aux déclarations de métadonnées.

  1. Le protocole HTTP et les déclarations meta permettent de définir plusieurs valeurs de langue. Ce n'est pas approprié pour l'étiquetage de la langue de traitement de texte, lequel doit être réalisé une langue à la fois. Au contraire, les valeurs de langues multiples sont appropriées pour déclarer la langue de documents destinés à des locuteurs de plusieurs langues. Les déclarations de langues avec attributs ne peuvent définir qu'une seule langue à la fois, elles sont donc moins appropriées pour indiquer la langue du public visé, mais parfaites pour l'étiquetage de la langue de traitement de texte.

  2. L'information de langue contenue dans les en-têtes HTTP est rarement utilisée par les navigateurs grand public pour des applications de traitement de texte, et cette mise en œuvre telle qu'elle existe est incohérente (cf. les résultats de tests). Malheureusement, il nous reste encore à identifier un agent utilisateur, ou une application, qui reconnaisse l'information déclarée dans une balise meta quand elle est présentée au traitement de texte. En revanche, l'information de langue déclarée dans la balise html est systématiquement reconnue.

  3. Puisque les changements de langue de traitement de texte dans le document ne peuvent être réalisés qu'avec des attributs, la logique voudrait qu'on utilise les attributs sur l'élément html pour exprimer la langue de traitement de texte par défaut du document.

  4. Il importe de toujours connaître la langue de traitement de texte par défaut du document, mais si le document n'est pas lu à partir d'un serveur, ou si l'auteur est dans l'incapacité d'effectuer le paramétrage nécessaire du serveur, l'en-tête de contenu HTTP ne sera pas disponible.

Vers la table des matières.4.2.2 Les approches alternatives aux métadonnées

Quand il s'agit de choisir entre l'en-tête HTTP et l'élément meta pour exprimer des informations sur le public visé, les éléments manquent pour avancer un conseil. D'une certaine façon, l'élément meta peut séduire car la déclaration se trouve dans le document. Elle évite des problèmes potentiels si l'auteur n'a pas accès au paramétrage du serveur, en particulier s'il traite avec un fournisseur de services Internet, ou si le document est lu à partir d'un CD ou d'une autre source non-HTTP. Quoiqu'il en soit, ce n'est que de la théorie tant que des cas d'utilisation plus pratiques ne se sont pas présentés.

Si, dans le futur, nous constatons une déclaration systématique dans le document de la langue du public avec l'élément meta, il sera peut-être acceptable aussi de déduire la langue du public visé de l'attribut de langue sur l'élément html pour les documents à audience monolingue. Toutefois, un débat entre les diverses parties prenantes doit avoir lieu avant de prendre une décision.

Pour le moment, on sait très peu de chose de l'intérêt d'utiliser l'approche Dublin Core mentionnée dans la section précédente. Dans l'esprit de certains, c'est peut-être une bonne raison de ne pas l'utiliser. Pour les déclarations de métadonnées dans le document, l'utilisation de l'élément meta de type Content-Language est déjà beaucoup plus répandue.

Vers la table des matières.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 :

Exemple n° 7 :

<html lang="fr-CA">

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 ».

Remarque : Cf. la section « 6 La déclaration de métadonnées pour la langue du public visé » pour des renseignements sur les déclarations utilisant l'en-tête HTTP ou la balise meta concernant la langue du public visé.

Ressources :

Informations générales

Liens aux références

Sources

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.

Exemple n° 8 :
<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.

Ressources :

Informations générales

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 :

Exemple n° 9 :

<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 :

Exemple n° 10 :

<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 ».

Ressources :

Informations générales

Liens aux références

Sources

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 :

Exemple n° 11 :

<html lang="fr-CA">

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.

Exemple n° 12 :

<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).

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.

Ressources :

Sources

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.

Comment faire : Utilisez les attributs lang et/ou xml:lang sur l'élément html. L'exemple n° 14 déclare un document HTML en français canadien :

Exemple n° 14 :

<html lang="fr-CA">

Discussion : La raison fondamentale en est que les agents utilisateurs courants utilisent rarement l'information dans l'en-tête HTTP ou l'élément meta pour les applications de langue de traitement de texte, et ces mises en œuvre telles qu'elles existent sont incohérentes (cf. les résultats des tests).

Tout cela est expliqué dans la section 4 Les mécanismes de déclaration de langues dans HTML.

Ressources :

Informations générales

Sources

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 :

Exemple n° 15 :

<html lang="fr-CA">

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.

Exemple n° 16 : Une façon inappropriée d'étiqueter la langue lorsque celle de la valeur d'attribut et celle du contenu de l'élément diffèrent.

<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.

Exemple n° 17 : Une meilleure façon d'étiqueter la langue lorsque celle de la valeur d'attribut et celle de l'élément diffèrent.

<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 ».

Ressources :

Sources

Vers la table des matières.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).

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.

Remarque : Cela diffère de l'expression de la langue de traitement de texte par défaut, laquelle devrait être réalisée à l'aide d'un attribut de langue sur la balise html (cf. la « Pratique exemplaire n° 1 : Utiliser les attributs dans la balise html »).

À 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.

Ressources :

Liens aux références

Sources

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 :

Exemple n° 19 :

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) :

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 :

Sources

  • La définition de Content-Language dans HTTP/1.1 (section 14.12).
    Content-Language

Vers la table des matières.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.

Ressources :

Comment faire :

Liens aux références

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).

Ressources :

Comment faire :

Liens aux références

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 : ie6  

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.

Exemple n° 21 : Chinois simplifié :

<p lang="zh-Hans" xml:lang="zh-Hans">当世界需要沟通时,请用统一码!</p>

Exemple n° 22 : Chinois traditionnel :

<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 :

  1. Que vous ayez paramétré les fontes appropriées dans vos préférences,

  2. Que le style du document n'indique pas de fonte, et

  3. 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.

Ressources :

Comment faire :

Liens aux références

Données de test

Vers la table des matières.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 : ie7   ie6  

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.

Exemple n° 23 :

Il y a également une page décrivant pourquoi une déclaration DOCTYPE est utile [sv].

Le balisage du paragraphe est le suivant :

Exemple n° 24 :

<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 :

Exemple n° 25 :

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.

Exemple n° 26 :

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 :

Exemple n° 27 :

Il y a également une page décrivant pourquoi une déclaration DOCTYPE est utile [en suédois].

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 :

Comment faire :

Sources

  • L'attribut hreflang dans la spécification HTML (section 12.2).
    L'élément a

Données de test

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.

Vers la table des matières.A Remerciements

Les membres de l'ex-groupe de travail GEO et l'ex-mission (task force) GEO ont contribué, en temps et avec leurs commentaires précieux, à former ces pratiques exemplaires. Ce sont :

Phil Arko (Siemens), Steve Billings (expert invité), David Clarke (expert invité), Deborah Cawkwell (BBC World Service), Wendy Chisholm (W3C WAI), Andrew Cunningham (State Library of Victoria), Martin Dürst (expert invité), Lloyd Honomichl (expert invité), Susan K. Miller (Boeing), Russ Rolfe (Microsoft), Peter Sigrist (expert invité), Tex Texin (Yahoo), Najib Tounsi (École Mohammadia d'Ingénieurs).