RFCs are what the IETF calls its specifications. Each RFC has a unique number. Unfortunately, it is not possible to tell, when reading RFC 1766 or RFC 3066 that these specifications have been obsoleted and replaced by other specifications.
-
Language tag syntax is defined by the IETF's BCP 47. BCP stands for 'Best Current Practice', and is a persistent name for a series of RFCs whose numbers change as they are updated. The latest RFC describing language tag syntax is RFC 5646, Tags for the Identification of Languages, and it obsoletes the older RFCs 4646, 3066 and 1766.
+
Language tag syntax is defined by the IETF's BCP 47. BCP stands for 'Best Current Practice', and is a persistent name for a series of RFCs whose numbers change as they are updated. The latest RFC describing language tag syntax is RFC 5646, Tags for the Identification of Languages, and it obsoletes the older RFCs 4646, 3066 and 1766.
You used to find subtags by consulting the lists of codes in various ISO standards, but now you can find all subtags in the IANA Language Subtag Registry. We will describe the new registry below.
@@ -233,7 +233,7 @@
Constructing language tags
class="puExample">privateuse
The entries in the registry follow certain conventions with regard to upper and lower letter-casing. For example, language tags are lower case,
-alphabetic region subtags are upper case, and script tags begin with an initial capital. This is only a convention! When you use these subtags you
+alphabetic region subtags are upper case, and script subtags begin with an initial capital. This is only a convention! When you use these subtags you
are free to do as you like, unless you are constrained by the rules of the system you are working with. For HTML and XML language markup, the case should not matter.
@@ -374,7 +374,8 @@
The extended language subtag
Description: Gulf Arabic
Added: 2009-07-29
Preferred-Value: afb
-Prefix: ar Macrolanguage: ar
+Prefix: ar
+Macrolanguage: ar
%%
@@ -398,8 +399,8 @@
Examples of language tags including script subtags are:
zh-Hans (Simplified Chinese)
-
az-Latn (Azerbaijani, written in Latin script - since Azerbaijani can also be written using the Arabic script)
+
az-Latn (Azerbaijani, written in Latin script - since Azerbaijani can also be written using the Arabic or Cyrillic script)
The script subtag was first introduced in RFC 4646. The subtags come from, and are kept up to date with, the list of ISO 15924 script codes.
Only one script subtag can appear in a language tag, and it must immediately follow the language or any extlang subtag. It is always four letters long.
-
You should only use script tags if they are necessary to make a distinction you need. As RFC 4646 co-author, Addison
-Phillips, writes, "For virtually any content that does not use a script tag today, it remains the best practice not to use one in the future".
+
You should only use script subtags if they are necessary to make a distinction you need. As RFC 4646 co-author, Addison
+Phillips, writes, "For virtually any content that does not use a script subtag today, it remains the best practice not to use one in the future".
If you specifically want to indicate that content is not written, there is a subtag for that. For example, you could use en-Zxxx to make it clear that an audio recording in English is not written content.
-
Actually, many language subtag entries in the registry strongly discourage the use of script tags by including a Suppress script field. There is such a field in the Spanish example above, which indicates that Spanish is normally written using Latin script, and so the Latn subtag should normally not be used with es.
+
Actually, many language subtag entries in the registry strongly discourage the use of script subtags by including a Suppress-script field. There is such a field in the Spanish example above, which indicates that Spanish is normally written using Latin script, and so the Latn subtag should normally not be used with es.
This example shows the registry entry for Cyrillic script, Cyrl, used for languages such as Russian:
The region subtag in RFC 3066 took its values from the ISO 3166 country codes. These two-letter codes are still available from the new registry, but the registry also lists 3-digit UN M.49 region codes. The advantage of these codes is that they can represent more than just countries. For example, localization groups have for some time wanted to label their carefully crafted translations as Latin-American Spanish, rather than the Spanish of any particular country. With RFC 5646 this is possible; the appropriate language tag is es-419.
-
Only one region subtag can appear in a language tag, and it must appear after the language subtag and any extlang and script tags. It is a two-letter alpha or 3-digit numeric code. You can have a language code immediately followed by a region code, just as you are used to for language tags such as en-US.
+
Only one region subtag can appear in a language tag, and it must appear after the language subtag and any extlang and script subtags. It is a two-letter alpha or 3-digit numeric code. You can have a language code immediately followed by a region code, just as you are used to for language tags such as en-US.
Once again, you should only use region subtags if they are necessary to make a distinction you need. Unless you specifically need to highlight that you are talking about Italian as spoken in Italy you should use it for Italian, and not it-IT. The same goes for any other possible combination.
@@ -544,7 +545,7 @@
Variant subtags
-
In the registry these subtags are tied to a specific language (and possibly additional subtags between this subtag and the primary language subtag) by the 'Prefix' field. The nedis example shown above should only be used with Slovenian.
+
In the registry these subtags are tied to a specific language (and possibly additional subtags between this subtag and the primary language subtag) by the Prefix field. The nedis example shown above should only be used with Slovenian.
If you need to express a particular dialectal or script nuance that is not currently available, you should propose a variant subtag or subtags for inclusion in the
registry using the registration procedure outlined in RFC 5646.
@@ -562,7 +563,7 @@
Extension and private-use subtags
Extension subtags
-
de-DE-u-co-phonebk
+
de-DE-u-co-phonebk
Private use subtags
en-US-x-twain
Read more in the BCP 47 spec:
@@ -578,9 +579,12 @@
Extension and private-use subtags
Extension and private use subtags are introduced by a single letter tag, or 'singleton'. An organization can propose a singleton for an extension. Its intended use must be described by an RFC (IETF specification). The singleton will be added to the registry if it successfully passes a review. The singleton x is reserved for private use. Multiple subtags are allowed after the singleton; however, as for all subtags, they must each be 8 or less characters in length.
+
+
A locale is an identifier (such as a language tag) for a set of international preferences. Usually this identifier indicates the preferred language of the user and possibly includes other information, such as a geographic region (such as a country). A locale is passed in APIs or set in the operating environment to obtain culturally-affected behavior within a system or process.
+
Extension subtags allow for extensions to the language tag. For example, the extension subtag u has been registered by the Unicode Consortium to add information about language or locale behavior. Many locale identifiers require additional "tailorings" or options for specific values within a language, culture, region, or other variation. This extension provides a mechanism for using these additional tailorings within language tags for general interchange.
-
For example, the following indicates that phonebook collation order should be used by an application, that sorted data in a document is sorted according to this collation, and so on.
+
For example, in the following tag, the u-co-phonebk extension indicates that phonebook collation order should be used by an application, that sorted data in a document is sorted according to this collation, and so on.
Grandfathered tags are special cases, provided for backwards compatibility. They are subtags that were registered before RFC 4646 that cannot be completely composed from the subtags in the current registry, or do not fit the syntax currently defined for language tags.
+
Grandfathered tags are special cases, provided for backwards compatibility. They are tags that were registered before RFC 4646 that cannot be completely composed from the subtags in the current registry, or do not fit the syntax currently defined for language tags.
Redundant tags are language tags composed of a sequence of subtags and registered before RFC 4646 that can now be formed by combining separate subtags from the current registry. The original registrations remain in the registry mostly 'as a matter of historical curiosity'.
-
Many grandfathered tags have been superceded by subtags or combinations of subtags in the registry. Such grandfathered tags are now deprecated, and usually contain a Preferred-Value field that indicates how you ought to represent that language instead. For instance, the following example of a grandfathered tag indicates that you should use the jbo language subtag instead of art-lojban.
+
Many grandfathered tags have been replaced by subtags or combinations of subtags in the registry. Such grandfathered tags are now deprecated, and usually contain a Preferred-Value field that indicates how you ought to represent that language instead. For instance, the following example of a grandfathered tag indicates that you should use the jbo language subtag instead of art-lojban.
@@ -666,9 +670,10 @@
Matching language tags
the word 'SALE' should not be red in the following code.
-
-
<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>
+
+
<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>
With the availability of additional tags in RFC 5646, matching is a little more complicated. In addition, its companion, RFC 4647 Matching of Language Tags, describes more than one possible approach to matching.
@@ -685,7 +690,7 @@
Note there have been changes to ISO language codes. In 1989 iw, in, and ji were withdrawn and replaced by he, id, and yi. More recently, the ISO country code cs, that used to represent Czechoslovakia, was changed to represent Serbia and Montenegro. Such changes can lead to confusion when comparing codes that were assigned to text over a long period. The new IANA subtag registry allows for tags to be deprecated and superseded by new tags, but will never remove or change the meaning of a subtag. It is expected that ISO will also follow a similar policy for the future.
diff --git a/articles/language-tags/index.fr.html b/articles/language-tags/index.fr.html
new file mode 100644
index 00000000..ff847ee7
--- /dev/null
+++ b/articles/language-tags/index.fr.html
@@ -0,0 +1,841 @@
+
+
+
+
+Les étiquettes de langues en HTML et XML
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Les étiquettes de langues en HTML et XML
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
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.
+
+
+
Aperçu
+
+
+
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 :
+
+
de sous-étiquettes pour désigner les composants d’une étiquette, ou
+
de codes pour désigner les éléments d’une liste ISO de langues ou de pays.
+
+
+
+
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
+
+
+
+
+
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 ?
+
+
+
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.
Pour trouver les sous-étiquettes valables, il fallait autrefois se référer aux listes de codes présents dans diverses normes ISO. Désormais, toutes les sous-étiquettes sont rassemblées dans le Registre IANA des sous-étiquettes de langues.
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.
+
+
+
+
+
+
+
+
+
Construction des étiquettes de langues
+
+
Les sections suivantes présentent les différents types de sous-étiquettes à votre disposition et expliquent comment les utiliser. En voici la liste :
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.
+
+
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 :
+
+
Les sous-étiquettes valables sont centralisées dans le nouveau registre IANA, ce qui évite d’avoir à consulter plusieurs documents pour les trouver.
+
Les sous-étiquettes ont des positions et des longueurs fixes, ce qui facilite la recherche de correspondance des étiquettes de langues.
+
La RFC 5646 offre une plus grande flexibilité quant aux composants potentiels d’une étiquette de langue.
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
+
Utilisation du registre des sous-étiquettes
+
+
Comme nous l’avons vu plus haut, pour trouver les sous-étiquettes à utiliser, il fallait autrefois consulter les listes de codes figurant dans diverses normes ISO. Désormais, toutes les sous-étiquettes sont rassemblées au même endroit, dans le registre IANA. 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 :
+
+
+
+
%%
+Type: language
+Subtag: fr
+Description: French
+Added: 2005-10-16
+Suppress-Script: Latn
+%%
+
+
+
+
+
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.
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)
+
+
+
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 :
+
+
+
+
%%
+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
+
+
+
Sous-étiquettes d’écriture
+
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. Bien entendu, il est possible que vous ayez encore besoin d’utiliser les anciennes étiquettes de langues dans certains cas à des fins de cohérence.
+
+
+
+
+
+
+
+
+
+
+
La sous-étiquette de région géographique
+
+
+
Sous-étiquettes de région
+
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 :
+
+
+
%%
+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
+
+
+
Sous-étiquettes de variante
+
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.
+
+
+
+
+
+
+
+
+
+
+
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.
+
+
+
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) :
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 (CLDR) 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
+
+
+
+
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 :
+
+
+
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.
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>
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.
Cette page offre quelques informations de base aux nouveaux venus dans le domaine de l’internationalisation Web qui ne savent pas vraiment par où commencer. Le but est de vous offrir une introduction simple à quelques contenus présents sur le site.
-
You can find a selection of more detailed articles using the links to the right. Once you get some ideas from this page, you will probably just use Learn to internationalize, or the site search.
+
À droite de chaque section, vous trouverez une sélection d’articles plus détaillés. Une fois que vous aurez parcouru cette page, vous n’aurez probablement besoin que des articles réunis dans notre guide d’internationalisation ou de la fonctionnalité de recherche sur ce site.