Copyright © 2007 W3C® (MIT, ERCIM, Keio), tous droits réservés. Les règles de responsabilité, de nom de marque et d'utilisation des documents du W3C s'appliquent.
Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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.
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.
html
html
pour des publics plurilingueslang
et xml:lang
Content-Language
et les attributsbody
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.
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.
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.
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).
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.
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.
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 »).
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.
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.
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.
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
".
meta
de type Dublin CoreComme 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.
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).
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
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.
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.
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.
Content-Language
: les différencesLes 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.
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.
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.
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.
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.
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.
html
,
sauf si le document offre un contenu destiné à des locuteurs de plusieurs langues.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 ».
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é.
lang
sur la balise html
(dans « Les techniques pour l'accessibilité du contenu Web Content pour HTML », section 2.2).lang
dans HTML 4.01 (dans « La spécification HTML 4.01 », section 8.1)lang
xml:lang
dans XML 1.0. (dans « La spécification XML 1.0 », section 2.12).xml:lang
et lang
dans XHTML 1.0 (section C.7)lang
et xml:lang
html
ou bien définir les langues plus tard.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.
Content-Language
ou un élément meta
de type Content-Language
? Article du W3C.meta
pour l'information de langueLe 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 ».
lang
et/ou xml:lang
autour du texte
pour indiquer les changements de langues.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 :
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 ».
lang
dans HTML 4.01 (dans « La spécification HTML 4.01 », section 8.1)lang
xml:lang
dans XML 1.0. (dans « La spécification XML 1.0 », section 2.12).xml:lang
et lang
dans XHTML 1.0 (section C.7)lang
et xml:lang
lang
lorsque la langue change dans un document (dans « Les techniques pour l'accessibilité du contenu Web Content pour HTML », section 2.1).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
.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
.
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).
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.
lang
dans HTML 4.01 (dans « La spécification HTML 4.01 », section 8.1)lang
xml:lang
dans XML 1.0. (dans « La spécification XML 1.0 », section 2.12).xml:lang
et lang
dans XHTML 1.0 (section C.7)lang
et xml:lang
meta
pour déclarer la
langue de traitement de texte par défaut.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 :
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.
Content-Language
ou un élément meta
de type Content-Language
? FAQ I18N du W3Cmeta
pour l'information de langueContent-Language
. Celle-ci dit uniquement que l'attribut de langue HTML
a une priorité plus élevée (dans « La spécification HTML 4.01 », section 8.1)lang
Content-Language
dans HTTP/1.1 (section 14.12).lang
dans HTML 4.01 (dans « La spécification HTML 4.01 », section 8.1)lang
xml:lang
dans XML 1.0. (dans « La spécification XML 1.0 », section 2.12).xml:lang
et lang
dans XHTML 1.0 (section C.7)lang
et xml:lang
body
,
utilisez l'élément html
.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.
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 ».
lang
dans HTML 4.01 (dans « La spécification HTML 4.01 », section 8.1)lang
xml:lang
dans XML 1.0. (dans « La spécification XML 1.0 », section 2.12).xml:lang
et lang
dans XHTML 1.0 (section C.7)lang
et xml:lang
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.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).
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.
Content-Language
ou un élément meta
de type Content-Language
? Article du W3C.meta
pour l'information de langueContent-Language
dans HTTP/1.1 (section 14.12).Content-Language
. Celle-ci dit uniquement que l'attribut de langue HTML
a une priorité plus élevée (dans « La spécification HTML 4.01 », section 8.1)lang
Content-Language
avec une liste de codes de langue séparés par des virgules.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 :
L'élément meta
de type Content-Language
dans le document offre une possibilité similaire
(cf. l'exemple n° 20) :
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).
Content-Language
dans HTTP/1.1 (section 14.12).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.
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).
zh-Hans
ou zh-Hant
pour désigner respectivement le chinois simplifié ou le chinois traditionnel.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.
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.
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.
a
est dans une autre langue,
examinez le pour et le contre d'utiliser hreflang
avec des feuilles de style CSS.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.
Il y a également une page décrivant pourquoi une déclaration DOCTYPE est utile [sv].
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 :
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.
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 :
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.
:before
et :after
dans la spécification CSS 2.1 (section 12.1).:before
et :after
hreflang
dans la spécification HTML (section 12.2).a
hreflang
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.
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).