Les étiquettes de langues en HTML et XML

Quelles sont les conventions en matière de casse ?

Les entrées du registre suivent certaines conventions en matière de casse. Par exemple :

• les étiquettes de langues sont en minuscules,
• les sous-étiquettes alphabétiques de région sont en majuscules et
• les sous-étiquettes d’écriture commencent par une majuscule.

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.

Comment fonctionne l’héritage de l’information de langue ?

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 :

• une information de langue différente ou
• une chaîne vide (par exemple, xml:lang="" en XML).

Une chaîne vide indique que vous ne voulez associer aucune information de langue à l’élément concerné.

Où est définie la syntaxe des étiquettes de langues ?

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.

Combien de sous-étiquettes faut-il utiliser ?

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.

La sous-étiquette de langue principale (Language)

en

ast

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 :

%%
Type: language
Subtag: es
Description: Spanish
Description: Castilian
Added: 2005-10-16
Suppress-Script: Latn
%%

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.

La sous-étiquette de langue étendue (Extlang)

zh-yue

ar-afb

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 :

%%
Type: extlang
Subtag: afb
Description: Gulf Arabic
Added: 2009-07-29
Preferred-Value: afb
Prefix: ar
Macrolanguage: ar
%%

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 :

• Quand on l’utilise seul, 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.
• Lorsqu’une clarté absolue est requise, vous pouvez utiliser le code du mandarin (cmn) à la place, à condition de préserver l’interopérabilité.
• Si vous utilisez 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.

La sous-étiquette d’écriture (Script)

zh-Hans

az-Latn

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 :

%%
Type: script
Subtag: Cyrl
Description: Cyrillic
Added: 2005-10-16
%%

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.

La sous-étiquette de région géographique (Region)

en-GB

es-005

zh-Hant-HK

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 :

%%
Type: region
Subtag: AT
Description: Austria
Added: 2005-10-16
%%
Type: region
Subtag: 015
Description: Northern Africa
Added: 2005-10-16
%%

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.

La sous-étiquette de variante (Variant)

sl-nedis

sl-IT-nedis

de-CH-1901

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 :

%%
Type: variant
Subtag: nedis
Description: Natisone dialect
Description: Nadiza dialect
Added: 2005-10-16
Prefix: sl
%%

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.

Les sous-étiquettes d’extension et à usage privé

Remarque : si vous pensez vraiment avoir besoin d’utiliser ces sous-étiquettes, vous devriez lire la spécification, plutôt que cet article.

de-DE-u-co-phonebk

en-US-x-twain

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

Les étiquettes exonérées et redondantes

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 :

• Les étiquettes exonérées sont des cas particuliers, prévus par souci de compatibilité descendante. Il s’agit d’étiquettes dont la syntaxe n’est pas conforme aux spécifications actuelles ou dont au moins une sous-étiquette est absente du registre actuel.
• Les étiquettes redondantes sont des étiquettes de langues que l’on peut désormais former en combinant des sous-étiquettes du registre actuel. Si les enregistrements originaux figurent toujours dans le registre, c’est principalement en tant que « curiosités historiques ».

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.

%%
Type: grandfathered 
Tag: art-lojban 
Description: Lojban 
Added: 2001-11-11 
Deprecated: 2003-09-02 
Preferred-Value: jbo 
%%

Changements introduits par la RFC 5646

Voici les principales caractéristiques qui distinguent la RFC 5646 de spécifications plus anciennes comme la RFC 3066 :

1. Les sous-étiquettes valables sont centralisées dans le nouveau registre IANA, ce qui évite d’avoir à consulter plusieurs documents pour les trouver.
2. Les sous-étiquettes ont des positions et des longueurs fixes, ce qui facilite la recherche de correspondance des étiquettes de langues.
3. La RFC 5646 offre une plus grande flexibilité quant aux composants potentiels d’une étiquette de langue.

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.

Modification des codes de langues

Les codes de langues ISO ont été modifiés :

• En 1989, les codes iw, in et ji ont été retirés et remplacés par he, id et yi.
• Plus récemment, le code de pays ISO 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.

Spécifications utilisant des étiquettes de langues

De nombreuses autres spécifications du W3C ou relatives au Web utilisent des étiquettes de langues :

• XHTML 1.0 utilise des étiquettes de langues dans l’attribut HTML lang et l’attribut XML xml:lang, ainsi que dans l’attribut hreflang.
• HTTP utilise des étiquettes de langues dans les en-têtes Accept-Language et Content-Language.
• SMIL et SVG peuvent utiliser des étiquettes de langues dans la déclaration switch.
• CSS et XSL utilisent des étiquettes de langues pour un contrôle précis du style.

Remarque : on peut déclarer des informations de langue sur des objets comme des images ou des fichiers audio inclus.