Spécifier la langue d'un document (X)HTML

En bref

Entre les attributs HTML, les éléments meta et les en-têtes HTTP, les moyens de spécifier la ou les langue(s) d'une page Web ne manquent pas. Mais la pratique montre l'existence de deux besoins bien différents en la matière : il importe de différencier langue primaire d'une ressource Web et langue de traitement d'un contenu, et d'utiliser à bon escient les outils à notre disposition pour les indiquer.

De nombreuses sources encouragent les auteurs à préciser la langue de leur document : les directives d'accessibilité, les bonnes pratiques qualités, les spécifications (X)HTML , les conseils pour l'internationalisation, l'optimisation du reférencement, etc. Le plus souvent, cette démarche semble d'autant plus simple que le document est rédigé dans une langue unique, ou comporte tout au plus quelques citations dans une autre langue. Cependant, même dans ces cas simples, ce sont en fait deux notions bien distinctes qui sont à l'oeuvre : les langues primaires de la ressource et les langues de traitement de son contenu. Toutes deux répondent à des problématiques opérationnelles différentes, que nous allons analyser ici. Nous pourrons alors déterminer quelles sont les techniques appropriées pour communiquer efficacement ces deux types d'informations aux agents utilisateurs, en précisant également les normes de codification des langues qui assureront la pertinence de ces informations.

Pourquoi spécifier la langue ?

Les informations de langue sont couramment jugées utiles à de multiples points de vue.

Par exemple, il est possible de servir un contenu différent à un utilisateur « à la demande », en fonction de la configuration de son client Web : on peut donc prévoir plusieurs versions linguistiques d'un même document et délivrer ce contenu en fonction des préférences de chaque utilisateur. L'ensemble de ces versions forme une ressource unique, caractérisée par la liste des langues dans lesquelles elle est disponible.

De même, il peut s'agir de faciliter et d'améliorer la précision du référencement d'une ressource dans des bases de données documentaires, dans des annuaires ou auprès de moteurs de recherche. Là encore, plusieurs langues peuvent éventuellement être associées à une seule ressource, afin d'indiquer que celle-ci est disponible pour différents publics linguistiques.

Dans ces deux premiers cas, l'information de langue ne porte donc pas nécessairement sur une langue unique. Elle donne d'autre part une indication globale sur la ressource Web prise dans son ensemble, et non sur le détail de son contenu.

Dans d'autres cas, en revanche, c'est à l'intérieur même du document que l'on va rencontrer des changements de langue d'une section à une autre, chaque section étant caractérisée par une langue unique. L'agent utilisateur devra alors être informé de ces changements, afin de restituer le contenu de la façon la plus juste et la plus compréhensible possible. Ce sera le cas, par exemple, dans les contextes suivants:

Cette fois, l'information de langue est contextuelle, et porte à chaque fois sur une langue unique : un terme à prononcer, à traduire ou à corriger appartient à une langue et à une seule.

Ce rapide examen de quelques cas courants nous montre donc que nous avons besoin de délivrer deux types d'informations de langue bien distinctes. Il est temps à présent de les définir précisément.

Langue primaire et langue de traitement

La langue primaire du document constitue en fait une métadonnée. Elle renseigne sur le document « pris comme un tout », et non sur telle ou telle partie de son contenu. Malgré l'ambiguïté de la norme HTML4.01 sur ce point, cette information n'est pas destinée au traitement du contenu, mais à celui de la page en tant que ressource Web, lorsqu'il s'agit par exemple d'adresser une version linguistique à l'utilisateur en fonction de ses préférences (autrement dit une représentation de la ressource parmi celles disponibles), ou d'indexer une ressource selon une langue de référence. On peut retenir comme règle que la ou les langues primaires du document désignent la ou les langues du public visé.

La langue de traitement du contenu, en revanche, est une donnée contextuelle qui va permettre aux agents utilisateurs de traiter le contenu de manière correcte. Ce contenu n'a qu'une seule langue de traitement, quel que soit ce dernier (synthèse vocale, affichage, traduction, etc.)

Prenons quelques exemples pour bien percevoir la nature de cette distinction :

Cette distinction étant à présent établie, quels sont les moyens appropriés pour préciser ces deux informations ?

Quelles techniques sont à notre disposition pour transmettre les différentes informations de langue ?

Plusieurs mécanismes distincts permettent de transmettre une information de langue concernant un contenu HTML : l'en-tête HTTP envoyée par le serveur, les éléments de metadonnées contenus dans la page, et enfin les attributs lang et xml:lang qui sont également indiqués dans le document lui-même.

Pour déterminer quels outils conviennent pour préciser respectivement langue primaire et langue de traitement, la clé est le fait que la langue de traitement du contenu est unique, alors que les langues primaires ne le sont pas nécessairement. Or :

Nous pouvons donc adopter à partir de ce constat des règles de bonnes pratiques simples.

Comment spécifier la ou les langues primaires d'un document

La ou les langues primaires d'une ressource seront indiquées via l'entête HTTP Content-Language :

Content-Language: fr
Content-Language: fr,en

Cette information sera reproduite via un élément meta :

Ceci garantit la permanence de l'information, que le document soit consulté en ligne ou après enregistrement local.

Notons que si plusieurs langues primaires doivent être indiquées, elles sont séparées dans tous les cas par des virgules, les espaces n'étant pas significatifs :

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

Spécifier la langue de traitement d'un contenu

L'élément html étant l'élément racine de tout document HTML, tout ce qu'il contient hérite par défaut de la valeur de ses attributs lang et/ou xml:lang. Tout le contenu de la page (title et autres meta compris) sera donc réputé être dans la langue ainsi indiquée, sauf précision contraire. On écrira donc :

Si une section quelconque du contenu a une langue différente, il suffit de l'indiquer dans les attributs lang et xml:lang de son élément conteneur. Par exemple, pour une citation en anglais dans un document en français :

Rappelons que l'attribut xml:lang est l'équivalent XML de l'attribut HTML lang. Pour des raisons de compatibilité, la spécification XHTML conseille d'utiliser simultanément les deux attributs lorsqu'on tire profit de la nature hybride du XHTML1.0 (à la fois HTML et XML) pour le servir avec le type de contenu text/html.

Les attributs lang et xml:lang peuvent être utilisés pour tous les éléments HTML, à l'exception de :

En l'absence d'un balisage spécifique et/ou d'attributs lang - xml:lang valides pour le conteneur (iframe par exemple), les éléments génériques div et span permettent de préciser un changement de langue en regroupant plusieurs éléments :

<div lang="en">
   <p>...</p>
   <ul>
      <li>...</li>
      <li>...</li>
   </ul>
</div>

Enfin, les attributs lang et xml:lang s'appliquent aussi bien au contenu des éléments (X)HTML qu'à celui de leurs attributs, comme le montre cet exemple donné pour l'élément link par la spécification HTML4.01 :

<link lang="en"
title="english version"
type="text/html"
rel="alternate"
hreflang="en"
href="http://example.org/english_doc.html">

Par défaut, la langue d'un attribut XHTML est donc celle de son élément. Il est impossible de préciser que la langue du contenu d'un attribut est différente de celle de l'élément concerné. Ceci concernerait concrètement par exemple :

<q lang="en" title="Ici, une information français">
Some english text
</q>

On évitera donc ce type de conflit en rédigeant dans la même langue le contenu de l'élément et celui de ses attributs.

Quel standard adopter pour la désignation des langues ?

La spécification HTML4.01 fait actuellement référence à la norme RFC1766 pour la désignation des langues. Celle-ci a cependant été actualisée par la norme RFC3066 qui doit donc être prise comme référence.

Concrètement, on utilisera un code de langue ISO639, du type en (anglais). Alors que ISO639-1 limitait à deux caractères les codes de langues, (soit 676 langues au plus), ISO639-2 étend à 3 le nombre de caractères des codes de langues (soit 17 576 codes possibles). Pour maintenir la compatibilité des documents antérieurs à ISO639-2 et garantir l'unicité des codes de langues utilisés, RFC3066 fixe les règles suivantes :

Dans tous les cas, il est indispensable de consulter le tableau de référence des codes ISO639 tenu à jour par la Bibliothèque du Congrès des Etats-Unis, qui en a officiellement la charge.

Ce code de langue peut être éventuellement suivi d'un ou plusieurs codes secondaires de pays (ISO3166), séparés par un tiret, du type en-US (anglais - Etats-Unis). Ce mécanisme est cependant d'une portée limitée, car il ne permet pas d'indiquer de nombreuses variantes linguistiques régionales (l'espagnol latino-américain exemple).

L'ensemble de ces codes sont indifférents à la casse selon RFC3066. ISO639 recommande (sans en faire une obligation) l'écriture des codes de langue en minuscules, tandis que l'usage est d'utiliser des majuscules pour les codes de pays.

D'autre part, certains auteurs sont parfois tentés de créer leurs propres codes de langue, ou de détourner le mécanisme de spécification de la langue pour faire référence à des données non linguistiques. Il s'agit fréquement d'une indication d'un langage de programmation, du type lang="PHP". Ces détournements sont dénués de sens : HTML4.01 précise en effet clairement que les langages informatiques sont explicitement exclus des codes de langue.

Notons enfin que deux codes de langues génériques, mul (Multilingue) et und (Langue indéterminée) n'ont pas lieu d'être utilisés en (X)HTML. RFC3066 précise en effet que :

Une question, une remarque ? Écrivez à l'auteur à editorial@openweb.eu.org .

Page valide XHTML 1 Strict, CSS2 et accessible AA.
Ce site s'affiche mieux dans un navigateur conforme aux standards, voici pourquoi.
Site hébergé par l' APINC et actualités dopées par Dotclear.