Remarque : cet article donne un aperçu général de la syntaxe et des concepts associés aux étiquettes de langues, tels que décrits dans la BCP 47. Si vous cherchez la marche à suivre pour choisir une étiquette de langue, vous devriez lire notre article Choisir une étiquette d’identification de langue.
Terminologie
On parle d’étiquette d’identification de langue ou d’étiquette de langue pour faire référence à la valeur d’un attribut de langue comme fr-CA
.
Pour faire référence à des éléments comme fr
et CA
, on parle :
Dans un document HTML ou XML, une étiquette d’identification de langue (comme fr-CA
) permet de préciser la langue du texte ou d’autres éléments. Elle s’utilise avec l’attribut lang
en HTML et l’attribut xml:lang
en XML.
La plupart des étiquettes de langues se composent d’une sous-étiquette de langue de deux ou trois lettres. Celle-ci est souvent suivie d’une sous-étiquette de région de deux lettres ou de trois chiffres.
En cas de besoin, vous pouvez y ajouter des sous-étiquettes de langue étendue, d’écriture, de variante, d’extension ou à usage privé. Vous trouverez plus d’explications à ce sujet dans la section Construction des étiquettes de langues ci-dessous.
Voici quelques exemples d’étiquettes d’identification de langues :
Étiquette | Langue | Types de sous-étiquettes |
---|---|---|
en |
Anglais | langue |
mas |
Maa (aussi appelé massaï) | langue |
fr-CA |
Français utilisé au Canada | langue+région |
es-419 |
Espagnol utilisé en Amérique latine | langue+région |
zh-Hans |
Chinois écrit à l’aide de l’écriture simplifiée | langue+écriture |
Les entrées du registre suivent certaines conventions en matière de casse. Par exemple :
Il s’agit seulement d’une convention ! Vous êtes libre d’utiliser ces sous-étiquettes comme bon vous semble, sauf si le système avec lequel vous travaillez vous impose des contraintes. Pour le balisage linguistique en HTML et en XML, la casse ne devrait avoir aucune importance.
En HTML comme en XML, l’information de langue déclarée sur un élément parent est transmise à ses enfants.
Vous pouvez toutefois empêcher l’héritage de l’information de langue à un élément enfant en déclarant sur ce dernier :
xml:lang=""
en XML).Une chaîne vide indique que vous ne voulez associer aucune information de langue à l’élément concerné.
Terminologie
Les BCP (de leur sigle anglais) sont des « bonnes pratiques actuelles ».
Les RFC (de leur sigle anglais) sont des « demandes de commentaires ». Il s’agit du nom que l’IETF donne à ses spécifications.
Chaque RFC est identifiée par un numéro unique. Malheureusement, en lisant la RFC 1766 ou la RFC 3066, il est impossible de deviner que ces spécifications sont désormais obsolètes ou qu’elles ont été remplacées.
La syntaxe des étiquettes de langues est définie dans la recommandation BCP 47 de l’IETF. « BCP 47 » est le nom permanent d’une série de RFC dont le numéro change à chaque mise à jour.
La dernière RFC de cette série est la RFC 5646, Étiquettes d’identification de langues. Ses prédécesseurs désormais obsolètes sont les RFC 4646 (traduction non officielle), 3066 et 1766.
Lors de la création d’étiquettes de langues, la règle d’or consiste à utiliser la forme la plus courte possible.
Évitez d’ajouter des sous-étiquettes supplémentaires (notamment de région ou d’écriture) lorsqu’elles n’apportent aucune information utile. Par exemple, pour le japonais, utilisez ja
et non ja-JP
, sauf si vous avez une bonne raison de préciser qu’il s’agit du japonais parlé au Japon, plutôt qu’ailleurs.
Vous trouverez dans la suite de cet article des informations supplémentaires sur la manière de construire vos étiquettes de langues.
Pour trouver les sous-étiquettes à utiliser, il fallait autrefois se référer aux les listes de codes présents dans diverses normes ISO. Désormais, toutes les sous-étiquettes sont rassemblées au même endroit, dans le Registre IANA des sous-étiquettes de langues. Un peu compliqué de prime abord (surtout par rapport aux listes de codes ISO), ce registre est assez simple d’utilisation une fois que l’on a compris sa structure.
Ce registre est un long fichier texte. Pour trouver une sous-étiquette de langue, il vous suffit de chercher sur la page le nom de la langue qui vous intéresse, en anglais. Par exemple, en cherchant « French » pour le français, on trouve l’entrée suivante :
Remarque : il s’agit d’une entrée de type language
(langue). L’information qui vous intéresse ici est la propriété Subtag
(sous-étiquette), qui a pour valeur fr
.
Vous pouvez trouver d’autres étiquettes de la même manière. Par exemple, si vous souhaitez vérifier que l’étiquette fr-CA
(français utilisé au Canada) est valable, vous devrez ensuite chercher Canada
et vérifier que l’entrée trouvée est de type region
.
Il y a toutefois d’autres choses à garder à l’esprit lors du choix des sous-étiquettes. Par exemple, vous devriez éviter les sous-étiquettes que le registre qualifie de redundant (redondantes) ou deprecated (déconseillées). Par ailleurs, vous devrez parfois utiliser des sous-étiquettes de variante en plus de certaines sous-étiquettes conseillées. Pour en savoir plus sur le choix des sous-étiquettes, consultez notre article Choisir une étiquette d’identification de langue.
Il existe également un outil non officiel, mais convivial pour effectuer une recherche dans le registre.
Dans les sections suivantes, vous trouverez des informations plus précises sur chaque sous-étiquette.
Les sections suivantes présentent les différents types de sous-étiquettes à votre disposition et expliquent comment les utiliser. En voici la liste :
language-extlang-script-region-variant-extension-privateuse
Sous-étiquettes Language
en
ast
Pour plus d’informations, consultez les sections suivantes de la spécification BCP 47 (en anglais) :
2.2.1 Sous-étiquette de langue principale
Toutes les étiquettes de langues doivent commencer par une sous-étiquette de langue principale.
Voici quelques exemples d’étiquettes de langues simples qui n’indiquent que la langue :
en
(anglais)ast
(asturien, langue pour laquelle les listes ISO ne prévoient aucun code de deux lettres)Voici également l’entrée du registre pour l’espagnol, es
, en tant que sous-étiquette de langue principale :
Les valeurs acceptées sont issues de la liste des codes de langues ISO 639 et tiennent compte de ses évolutions.
La RFC 3066 ne prévoyait aucune liste de sous-étiquettes valables et renvoyait les internautes vers la liste ISO 639. Cela pouvait prêter à confusion lorsque les listes de code ISO proposaient à la fois des codes de deux lettres et des codes de trois lettres (et même, parfois, plusieurs codes de trois lettres).
Désormais, toutes les sous-étiquettes valables sont centralisées dans le registre IANA, qui adopte une seule valeur issue des listes ISO pour chaque langue. Lorsqu’il existe un code ISO de deux lettres, c’est celui-ci que l’on trouve dans le registre. Dans le cas contraire, le registre indique un code de trois lettres. Cela devrait simplifier les choses.
Lors de la publication de la RFC 5646, plus de 7 000 nouveaux codes de trois lettres de la liste ISO 639-3 ont été ajoutés au registre des sous-étiquettes.
Bien que la casse n’ait aucune importance, les codes sont généralement écrits en minuscules. Il s’agit d’une simple convention.
Sous-étiquettes Extlang
zh-yue
ar-afb
Pour plus d’informations, consultez les sections suivantes de la spécification BCP 47 (en anglais) :
Pour faire référence aux sous-étiquettes de langue étendue, on parle de sous-étiquettes extlang.
Une étiquette de langue ne peut contenir qu’une seule sous-étiquette extlang. Celle-ci doit toujours être précédée d’une sous-étiquette de langue principale et doit précéder toutes les autres sous-étiquettes éventuelles.
Voici quelques exemples d’étiquettes de langues qui incluent des sous-étiquettes extlang :
zh-yue
(chinois cantonais)ar-afb
(arabe du Golfe)Remarque : les combinaisons langue+extlang sont proposées à des fins de compatibilité avec les anciens formats d’étiquette de langue. Toutefois, il existe une sous-étiquette de langue pour chaque combinaison langue+extlang. Vous devriez utiliser cette sous-étiquette de langue à la place de la combinaison langue+extlang, lorsque cela est possible.
Par exemple, si vous avez le choix, mieux vaut utiliser yue
plutôt que zh-yue
pour le cantonais et afb
plutôt que ar-afb
pour l’arabe du Golfe.
Les sous-étiquettes de langue étendue comportent toujours trois lettres. Chaque entrée extlang
du registre contient un champ Prefix
(préfixe) qui indique quelle langue doit précéder la sous-étiquette de langue étendue. Les entrées incluent aussi un champ Preferred-Value
(valeur préférée) qui indique l’étiquette de langue équivalente.
À titre d’exemple, voici l’entrée du registre pour l’arabe du Golfe, afb
, en tant que code de langue étendue :
Les macrolangues. Une sous-étiquette de langue principale qui s’accompagne d’une sous-étiquette extlang est appelée macrolangue (en anglais, macrolanguage). Une macrolangue englobe un certain nombre de langues pour lesquelles il existe des sous-étiquettes de langue principale plus précises.
Une macrolangue peut être utilisée seule. Mais s’il n’existe aucune convention quant à la manière de l’interpréter dans son contexte d’utilisation, cette information risque de manquer de précision.
Par exemple, le code zh
désigne le chinois, mais englobe de nombreux dialectes chinois, souvent incompréhensibles entre eux. Il s’agit donc d’une macrolangue. Parmi les langues englobées, la langue prédominante est le mandarin. Par conséquent :
zh
fait généralement référence à la langue prédominante parmi les langues englobées (le mandarin), bien que la BCP 47 ne le précise pas explicitement.
cmn
) à la place, à condition de préserver l’interopérabilité.zh
pour représenter une autre langue chinoise que le mandarin, comme le hakka, vous feriez mieux de le remplacer par le code explicite (dans cet exemple, hak
).À l’inverse, zh-Hans
utilise zh
dans son sens générique. C’est un bon moyen d’indiquer que l’on écrit en chinois simplifié, puisque le chinois s’écrit souvent de la même manière, quel que soit le dialecte.
Sous-étiquettes Script
zh-Hans
az-Latn
Pour plus d’informations, consultez les sections suivantes de la spécification BCP 47 (en anglais) :
Une étiquette de langue ne peut comporter qu’une seule sous-étiquette d’écriture. Celle-ci doit se trouver juste après la sous-étiquette de langue ou toute sous-étiquette extlang éventuelle. Elle comporte toujours quatre lettres.
Voici quelques exemples d’étiquettes de langues qui incluent des sous-étiquettes d’écriture :
zh-Hans
(chinois simplifié)az-Latn
(azerbaïdjanais écrit à l’aide de l’écriture latine, car on peut aussi écrire cette langue à l’aide de l’écriture arabe ou cyrillique)Voici également l’entrée du registre pour l’écriture cyrillique, Cyrl
, que l’on utilise pour représenter des langues comme le russe :
La sous-étiquette d’écriture a fait sa première apparition dans la RFC 4646. Les valeurs possibles sont issues de la liste des codes d’écriture ISO 15924 et tiennent compte de ses évolutions.
Si vous souhaitez indiquer spécifiquement qu’un contenu n’est pas écrit, il existe une sous-étiquette pour cela. Par exemple, vous pourriez utiliser en-Zxxx
pour indiquer clairement qu’un enregistrement audio en anglais n’est pas un contenu écrit.
Vous ne devriez utiliser de sous-étiquettes d’écriture que lorsqu’elles sont nécessaires à la distinction dont vous avez besoin. Comme l’écrit Addison Phillips, co-auteur de la RFC 4646, « Pour presque tous les contenus qui n’ont pas de sous-étiquette d’écriture à l’heure actuelle, la bonne pratique reste de ne pas leur en ajouter une ».
En réalité, de nombreuses entrées du registre des sous-étiquettes de langues déconseillent vivement l’utilisation de sous-étiquettes d’écriture. Elles incluent pour cela un champ Suppress-script
(écriture à supprimer). Ce champ est présent dans l’entrée du registre pour l’espagnol que nous avons vue plus haut. Il indique que l’espagnol s’écrit habituellement à l’aide de l’écriture latine et que l’on ne devrait pas, en principe, utiliser la sous-étiquette Latn
avec es
.
Dans les cas d’utilisation courants des étiquettes de langues, vous devrez rarement préciser l’écriture. Pourtant, il y a bien une ou deux langues pour lesquelles cette fonctionnalité était très attendue. L’une d’elles est le chinois.
Il existe de nombreux dialectes chinois, souvent mutuellement inintelligibles, mais tous s’écrivent à l’aide de l’écriture chinoise traditionnelle ou simplifiée. Les personnes qui créent du contenu veulent généralement préciser si un texte utilise l’écriture simplifiée ou l’écriture traditionnelle.
Encore récemment, il n’existait aucun moyen de le faire. Elles étaient donc contraintes de détourner les étiquettes de langues comme zh-CN
(qui correspond au chinois parlé en Chine) pour indiquer qu’un texte était écrit en chinois simplifié, même à Singapour, et zh-TW
(soit le chinois parlé à Taïwan) pour faire référence au chinois traditionnel. (D’autres personnes utilisent cependant zh-HK
pour le chinois traditionnel.)
Désormais, elles peuvent utiliser les étiquettes de langues zh-Hans
et zh-Hant
qui correspondent au chinois écrit respectivement avec l’écriture simplifiée et avec l’écriture traditionnelle. Ces nouvelles étiquettes déjà très répandues devraient améliorer la cohérence et la précision.
Sous-étiquettes Region
en-GB
es-005
zh-Hant-HK
Pour plus d’informations, consultez les sections suivantes de la spécification BCP 47 (en anglais) :
Une étiquette de langue ne peut comporter qu’une seule sous-étiquette de région. Celle-ci doit se trouver après la sous-étiquette de langue et après toute sous-étiquette de langue étendue ou d’écriture éventuelle. Il s’agit d’un code alphabétique de deux lettres ou d’un code numérique de trois chiffres.
Vous pouvez indiquer un code de langue immédiatement suivi d’un code de région, comme vous en avez l’habitude avec les étiquettes telles que en-US
.
Voici des exemples d’étiquettes de langues qui incluent des sous-étiquettes de région :
en-GB
(anglais britannique)es-005
(espagnol d’Amérique du Sud)zh-Hant-HK
(chinois traditionnel utilisé à Hong Kong)Voici également deux entrées du registre qui montrent les codes associés à l’Autriche, AT
, et à l’Afrique du Nord, 015
:
Dans la RFC 3066, les valeurs des sous-étiquettes de région étaient issues des codes de pays de la norme ISO 3166. Ces codes de deux lettres se retrouvent dans le nouveau registre, mais celui-ci inclut également les codes de région ONU M.49 de trois chiffres.
Ces codes présentent l’avantage de pouvoir représenter plus que des pays. Par exemple, des groupes de localisation souhaitaient depuis longtemps préciser que la langue de leurs traductions soigneusement confectionnées était l’espagnol d’Amérique latine, plutôt que l’espagnol d’un pays précis. Depuis la RFC 5646, c’est désormais possible ; il suffit d’utiliser l’étiquette de langue es-419
.
Une fois de plus, vous ne devriez utiliser de sous-étiquettes de région que lorsqu’elles sont nécessaires à la distinction dont vous avez besoin. Si vous n’avez pas besoin de souligner que vous faites référence à l’italien parlé en Italie, vous devriez utiliser it
et non it-IT
pour l’italien. C’est également valable pour toute autre combinaison possible.
Sous-étiquettes Variant
sl-nedis
sl-IT-nedis
de-CH-1901
Pour plus d’informations, consultez les sections suivantes de la spécification BCP 47 (en anglais) :
On utilise une sous-étiquette de variante pour préciser une variante dialectale ou orthographique, lorsque celle-ci n’est pas couverte par une combinaison de sous-étiquettes de langue, d’écriture et de région. Il est peu probable que vous ayez besoin d’en utiliser, à moins de travailler dans un domaine spécialisé.
La sous-étiquette de variante doit se trouver après toute sous-étiquette de langue, d’écriture ou de région. Toutefois, les sous-étiquettes d’écriture et de région sont facultatives.
Voici quelques exemples qui devraient vous aider à comprendre l’intérêt de ces sous-étiquettes :
sl-nedis
(le dialecte slovène de la vallée du Natisone)sl-rozaj
(le dialecte slovène de la vallée de Resia)sl-IT-nedis
(la variante précise du dialecte slovène de la vallée du Natisone qui est parlée en Italie)de-CH-1901
(la variante de l’orthographe allemande qui date des réformes de 1901, telle qu’adoptée en Suisse)Voici également l’entrée du registre qui montre le code du dialecte slovène de la vallée du Natisone, nedis
:
Dans le registre, chaque sous-étiquette de variante est liée à une langue précise par le champ Prefix
. Dans l’exemple de nedis
ci-dessus, ce champ indique que cette sous-étiquette ne devrait être utilisée qu’avec le slovène. Le champ Prefix
indique parfois des sous-étiquettes supplémentaires qui doivent apparaître entre cette sous-étiquette et la sous-étiquette de langue principale.
Il est possible que vous deviez exprimer une nuance particulière (relative à un dialecte ou à une écriture) qui n’est pas encore disponible. Dans ce cas, vous devriez proposer l’ajout d’une ou de plusieurs sous-étiquettes de variante au registre. La procédure d’enregistrement est décrite dans la RFC 5646.
Remarque : si vous pensez vraiment avoir besoin d’utiliser ces sous-étiquettes, vous devriez lire la spécification, plutôt que cet article.
Sous-étiquettes d’extension
de-DE-u-co-phonebk
Sous-étiquettes à usage privé
en-US-x-twain
Pour plus d’informations, consultez les sections suivantes de la spécification BCP 47 (en anglais) :
2.2.7 Sous-étiquettes à usage privé
Les sous-étiquettes d’extension et les sous-étiquettes à usage privé sont introduites par une étiquette d’une seule lettre, aussi appelée « singleton ». Plusieurs sous-étiquettes peuvent être placées après le singleton ; toutefois, comme toutes les sous-étiquettes, aucune d’elles ne doit comporter plus de huit caractères.
Les sous-étiquettes d’extension. Les sous-étiquettes d’extension permettent d’ajouter des extensions à l’étiquette de langue. Toute organisation peut proposer un singleton pour une extension. L’utilisation prévue doit être décrite par une RFC (spécification de l’IETF). La proposition sera examinée ; si le singleton est retenu, il sera ajouté au registre.
Par exemple, le Consortium Unicode a enregistré la sous-étiquette d’extension u
pour ajouter des informations sur le comportement de la langue ou de la région. De nombreux identifiants régionaux nécessitent des options supplémentaires « sur mesure » avec des valeurs spécifiques au sein d’une langue, d’une culture, d’une région ou d’une variante. Cette extension permet d’utiliser ces options dans les étiquettes de langues pour un libre échange des données.
Ainsi, dans l’étiquette suivante, l’extension u-co-phonebk
indique qu’une application devrait suivre la convention de tri de l’annuaire téléphonique, que les données triées dans un document sont triées selon cette convention, et ainsi de suite.
de-DE-u-co-phonebk
L’extension u-
est définie dans la RFC 6067, qui renvoie vers le Common Locale Data Repository (répertoire de données de paramètres régionaux classiques) du Consortium Unicode pour plus d’informations sur les sous-étiquettes qui la suivent. Elle n’est pas définie par la BCP 47.
Les sous-étiquettes à usage privé. Le singleton x
est réservé à l’usage privé. Les sous-étiquettes à usage privé sont absentes du registre des sous-étiquettes : elles sont choisies et conservées par accord privé entre les parties.
Ces sous-étiquettes n’ont vraiment de sens que dans le cadre d’un accord privé. Elles ne peuvent pas être utilisées n’importe où. Vous devriez donc les utiliser avec une grande prudence et uniquement en dernier recours.
Voici un exemple de sous-étiquette à usage privé qui identifie un type précis d’anglais américain, mais seulement au sein d’une communauté fermée :
en-US-x-twain
En dehors de cet accord privé, elle n’aura aucun sens (ou, si elle en a un, il pourra être différent).
Pour plus d’informations, consultez la section suivante de la spécification BCP 47 (en anglais) :
Les étiquettes exonérées et les étiquettes redondantes sont des étiquettes composées de plusieurs éléments et enregistrées avant la RFC 4646 :
De nombreuses étiquettes exonérées ont été remplacées par des sous-étiquettes ou des combinaisons de sous-étiquettes présentes dans le registre. Ces étiquettes exonérées sont désormais déconseillées. Leur entrée dans le registre contient généralement un champ Preferred-Value
(valeur à privilégier) qui indique l’alternative recommandée pour représenter cette langue.
À titre d’exemple, voici une étiquette exonérée qui recommande d’utiliser la sous-étiquette de langue jbo
à la place de art-lojban
.
La recherche de correspondance entre différentes étiquettes de langues est importante à un certain nombre d’applications.
D’après la BCP 47, on peut considérer que en
correspond à en-GB
. Par exemple, le code CSS suivant colore en rouge le texte en anglais dans les navigateurs compatibles avec la pseudo-classe :lang
.
:lang(en) { color: red; }
Dans le code ci-dessous, le texte décrit par lang="en-GB"
s’affichera donc en rouge.
<p>En janvier, toutes les boutiques de Londres affichent des panneaux <span lang="en-GB">SALE</span>, mais en fait ces magasins sont bien propres !</p>
Cependant, avec la déclaration CSS suivante :
:lang(en-GB) { color: red; }
le mot « SALE » ne devrait pas s’afficher en rouge dans le code ci-dessous :
<p>En janvier, toutes les boutiques de Londres affichent des panneaux <span lang="en">SALE</span>, mais en fait ces magasins sont bien propres !</p>
L’apparition d’étiquettes supplémentaires dans la RFC 5646 complique légèrement la recherche de correspondance. Celle-ci s’accompagne de la RFC 4647, Correspondance des étiquettes de langues (traduction non officielle), qui décrit plusieurs approches possibles de cette opération.
Nous décrirons la correspondance dans un autre article.
Les étiquettes de langues pour HTML ont fait l’objet d’une première définition formelle dans la RFC 2070, Internationalisation du langage de balisage hypertexte, de F. Yergeau et al. (traduction non officielle). La RFC 2070 a été intégrée au HTML 4 et n’a plus désormais qu’une valeur historique.
Voici les principales caractéristiques qui distinguent la RFC 5646 de spécifications plus anciennes comme la RFC 3066 :
Avec la RFC 3066, on pouvait composer des étiquettes de langues à partir d’un code de langue seul, d’un code de langue suivi d’un code de pays, ou d’un petit nombre de valeurs spéciales enregistrées dans le registre IANA des étiquettes de langues. Désormais, la RFC 5646 prévoit des types de sous-étiquettes supplémentaires qu’elle vous permet de combiner de diverses manières.
Bien qu’elle propose des options supplémentaires pour identifier les variations courantes des langues, la RFC 5646 inclut toutes les étiquettes qui étaient déjà valables jusque-là. Si vous utilisez la RFC 1766, la RFC 3066 ou la RFC 4646, vous n’aurez pas besoin de modifier vos étiquettes.
Si vous pensez que ce changement complique grandement les choses, rassurez-vous ! De façon générale, le choix des étiquettes de langues reste simple, et des sous-étiquettes supplémentaires sont à votre disposition lorsque vous devez faire des déclarations plus précises. En réalité, la RFC 5646 devrait simplifier la vie de la plupart des personnes qui s’y réfèrent. La centralisation des sous-étiquettes valables n’est qu’un exemple parmi d’autres.
Les codes de langues ISO ont été modifiés :
iw
, in
et ji
ont été retirés et remplacés par he
, id
et yi
.cs
, qui représentait la Tchécoslovaquie, a été modifié afin de représenter la Serbie et le Monténégro.Ces modifications peuvent prêter à confusion lorsque l’on compare les codes qui étaient associés à un texte sur une longue période.
Le nouveau registre IANA des sous-étiquettes peut déconseiller des étiquettes et les remplacer par de nouvelles étiquettes, mais ne retirera ni ne modifiera jamais la signification d’une sous-étiquette. L’ISO appliquera probablement une politique similaire à l’avenir.
De nombreuses autres spécifications du W3C ou relatives au Web utilisent des étiquettes de langues :
lang
et l’attribut XML xml:lang
, ainsi que dans l’attribut hreflang
.Accept-Language
et Content-Language
.switch
.Remarque : on peut déclarer des informations de langue sur des objets comme des images ou des fichiers audio inclus.
Vous débutez ? Les langues sur le Web
Liens connexes, Créer du contenu HTML et CSS
Liens connexes, Créer du contenu XML
Liens connexes, Créer du contenu SVG
Liens connexes, Développer des schémas