Les étiquettes d’identification de langues IETF (où le sigle désigne l'Internet Engineering Task Force) sont issues d’un code standardisé qui permet d’attribuer des étiquettes structurées et hiérarchisées permettant d’identifier les langues ou familles et collections de langues ou variétés linguistiques de ces langues. Elles ne sont pas réservées aux seules données et documents écrits, mais peuvent étiqueter aussi des contenus audio, multimédia, ou tout type de données de localisation dépendantes de la langue et d’autres paramètres de nature linguistique.
Elles sont définies par la recommandation standard BCP 47 de l’IETF, qui est mis à jour régulièrement et référence toujours les dernières RFC normatives applicables (et leurs corrections et errata éventuels), qui en précise la syntaxe normative, la définition, la validité et l’utilisation dans les logiciels (notamment pour établir des correspondances et équivalences entre étiquettes) ; cette recommandation est actuellement composée des RFC 5646[1] (successeur de RFC 4646[2]) et RFC 4647[3].
Elles sont associées à un registre des éléments utilisables pour leur composition ; ce registre est maintenu et hébergé par l’IANA (actuellement intégré à l’ICANN)[4]. D’autres RFC informatives sont également publiées lors de mises à jour majeures du registre mais non remises à jour de façon exhaustive, le registre assurant lui-même pour le compte de l’IETF la maintenance des données qu’il contient, selon la politique et les protocoles définis dans les RFC normatives.
Syntaxe
Une étiquette de langue complète (Language-Tag) est composée de sous-étiquettes (Subtag), chacune sur 1 à 8 caractères alphanumériques de 0 à 9 ou de a à z (la casse recommandée est, sauf indication contraire, en minuscules, même si elle est non significative) et séparées par des tirets simples (-). La syntaxe générale (simplifiée) en ABNF correspond à :
Language-Tag = Subtag *( "-" Subtag ) Subtag = 1*8alphanum
Cependant une étiquette complète doit correspondre de façon plus précise à l’un des formats définis ci-dessous (liste exhaustive), reconnaissable selon la première sous-étiquette utilisée. Les langues construites sont également codables localement au moyen de la sous-étiquette x
. Par exemple, art-x-pandunia
peut être utilisé pour le pandunia.
Format standard d'étiquettes
Le format standard codifie, dans l’ordre, les ensembles de sous-étiquettes suivants :
Sous-étiquettes pour indiquer et préciser la langue de base
- Une sous-étiquette de langue (issue normalement de la norme ISO 639 mais inscrite dans le registre IANA dans une entrée
Language:
deType:Subtag
) :
obligatoire[N 1], sur 2 ou 3 lettres (les sous-étiquettes à 4 lettres sont réservées aux extensions futures de la norme ISO 639), ou de 5 à 8 lettres ; quand plusieurs sous-étiquettes existent pour une même langue (ou si une sous-étiquette est rendue obsolète), on utilise normalement la plus courte, les autres sont des alias synonymes (mais non recommandés).- Note : des codes langues sont parfois supprimés de l’ISO 639. Cependant pour la stabilité des étiquettes de langues, les sous-étiquettes de langue correspondantes restent valides mais sont dépréciées (le registre mentionne une entrée
Deprecated:
) ; ces sous-étiquettes gardées pour la compatibilité ascendante peuvent alors éventuellement devenir des alias synonymes d’une autre sous-étiquette de langue, mentionnée dans le registre IANA par une entréePreferred:
mentionnant la nouvelle valeur recommandée à utiliser, si celle-ci est unique (sinon ces sous-étiquettes dépréciées sont à éviter car leur interprétation est ambiguë).
- Note : des codes langues sont parfois supprimés de l’ISO 639. Cependant pour la stabilité des étiquettes de langues, les sous-étiquettes de langue correspondantes restent valides mais sont dépréciées (le registre mentionne une entrée
- Jusqu’à trois sous-étiquettes d’extension de langue (inscrites dans le registre IANA dans une entrée
Extlang:
deType:Subtag
) :
optionnelles, sur 3 lettres chacune. Ces extensions sont spécifiques à la sous-étiquette de langue (qui ne peut être que sur 2 ou 3 lettres) ; depuis la normalisation d’ISO 639-3, ces sous-étiquettes d’extension de langues ne sont plus recommandés et chaque ensemble autorisé de sous-étiquettes (langue de base plus extensions) est devenu un alias synonyme d’un autre code langue ISO 639 normalisé.
Sous-étiquette de précision du système d’écriture utilisé
- Au plus une seule sous-étiquette d’écriture (issue normalement de la norme ISO 15924 mais inscrite dans le registre IANA dans une entrée
Script:
deType:Subtag
) :
optionnelle, sur 4 lettres (la casse recommandée des lettres est en minuscules sauf la première en majuscule). Toutes les sous-étiquettes possibles ne correspondent pas nécessairement à des langues écrites ou à des écritures déchiffrées, et certaines sous-étiquettes correspondent à des familles d’écritures ou à des variantes graphiques d’un même système d’écriture.
Sous-étiquettes de précision de variétés linguistiques
- Au plus une seule sous-étiquette de région géographique (normalement issue de la norme ISO 3166-1 mais restreinte aux seuls codes de pays, ou du standard UN M.49 pour les régions internationales à l’exclusion des pays et des régions économiques, mais inscrite dans le registre IANA dans une entrée
Region:
deType:Subtag
) :
optionnelle, sur 2 lettres (la casse recommandée des lettres est en majuscules) ou 3 chiffres ; quand plusieurs sous-étiquettes existent pour un pays ou une région, on utilise normalement la plus courte, les autres sont définies comme des alias synonymes (mais non recommandés). - D’éventuelles sous-étiquettes pour coder des variantes dialectales ou orthographiques (spécifiques pour une ou plusieurs langues, inscrites dans le registre IANA dans une entrée
Variant:
deType:Subtag
et avec l’indication des langues pour lesquelles la variante est applicable avecPrefix:
) :
de 4 à 8 caractères alphanumériques ou plus chacune (mais 5 caractères minimum si la sous-étiquette ne commence pas par un chiffre de 0 à 9). Certaines de ces sous-étiquettes, utilisées après les sous-étiquettes de langue et ou de région, sont devenues obsolètes et l'ensemble correspondant (langue + région géographique + variantes) a été remplacé par un autre code langue standard, l'ensemble devenant une étiquette synonyme (non recommandée).
Sous-étiquettes d’extension
- D’éventuels ensembles de sous-étiquettes pour les extensions normalisées :
1 seule lettre (sauf x) dans la première sous-étiquette dite « singleton » pour coder le type d’extension normalisée (inscrite dans le registre IANA avec dans une entréeSingleton:
deType:Subtag
), et de 2 à 8 caractères alphanumériques dans la (ou les) sous-étiquette(s) suivante(s) pour coder des valeurs qui seront interprétées selon le type d’extension normalisée ; les extensions normalisées peuvent être réordonnées automatiquement ensemble par ensemble (préférablement dans l’ordre ascendant des types d’extension), mais ne doivent apparaître qu’une seule fois (si nécessaire, on codera plusieurs sous-étiquettes successives dans la même extension). Les sous-étiquettes après le singleton initial obéissent à une syntaxe et un ordre spécifique à chaque type d’extension. Notes :- Depuis la normalisation d’ISO 639-3, les sous-étiquettes géographiques ne sont plus recommandées pour la représentation des langues humaines et variétés dialectales (mais continuent à être utilisées pour coder des préférences de localisation autres que la seule langue) ;
- Un type d’extension normalisée a été réservé par le Consortium Unicode afin d’ajouter des données de localisation autres que la seule langue (notamment pour le projet CLDR, par exemple une convention de tri ou l’indication d’un format de dates ou de nombres) ; elle utilise la sous-étiquette de type d’extension « u » (dans l’état actuel de la normalisation, ce type d’extension ne devrait pas être encore utilisé sur Wikipédia) ;
- Un autre type d’extension normalisée a été réservé aussi par le Consortium Unicode afin d’ajouter des données indicatrices d’une transformation de texte (utilisée aussi pour le projet CLDR, par exemple une restriction de méthode d’entrée ou la mention de l’écriture d’origine d’une translittération et l’identification de la méthode utilisée) ; elle utilise la sous-étiquette de type d’extension t.
- Une éventuelle extension d’utilisation privée (private use, non inscrite dans le registre IANA) :
la sous-étiquette constante « x », suivie d'une ou plusieurs sous-étiquettes de 1 à 8 caractères alphanumériques, destinées à coder des variantes dialectales et orthographiques non normalisées ou d’autres types de données de localisation de nature non linguistique (ce type d’extension privé ne devrait pas être utilisé sur Wikipédia).
Ancien format d’étiquettes dans le registre IANA
Un ancien format utilisé dans le registre IANA a servi à coder des langues qui étaient alors non mentionnées dans la norme ISO 639. Cet ancien format se compose des sous-étiquettes suivantes :
- La sous-étiquette constante « i » (pour le registre « IANA ») ;
- Une ou plusieurs autres sous-étiquettes, chacune sur 1 à 8 caractères alphanumériques (obligatoirement inscrites dans le registre IANA dans une entrée
Language:
avecType:Tag
), pour coder ensemble (et dans l’ordre mentionné dans le registre) une langue spécifique.
Ces étiquettes historiques sont encore valides, mais sont devenues des alias synonymes (non recommandés) d'une étiquette au format standard : toutes les langues qui étaient auparavant représentées dans le registre IANA uniquement avec des étiquettes dans ce format sont aujourd’hui maintenant représentables avec une étiquette au format standard mentionnée dans le registre lui-même (cet ancien format ne devrait plus être utilisé sur Wikipédia).
Format d’étiquettes d’utilisation privée
Le format d’utilisation privé (private use, non inscrit dans le registre IANA), se compose des sous-étiquettes suivantes :
- La sous-étiquette constante « x » (pour « eXtension privée ») ;
- Une ou plusieurs autres sous-étiquettes, de 1 à 8 caractères alphanumériques chacune (non inscrites dans le registre IANA) pour coder une information privée (pas nécessairement pour identifier une langue).
On peut noter que le format standard inclut aussi toutes les sous-étiquettes d’utilisation privée, définies pour les langues, familles et collections de langues, pour les systèmes, styles ou familles d’écriture, et pour les régions géographiques (provenant des normes ISO où elles ont été définies en tant qu’identifiants avant d’être importées dans le registre IANA), ainsi que des sous-étiquettes d’extension.
Ce format devrait être évité sur la plupart des sites Internet pour identifier des langues (y compris dans les pages Wikipédia, en dehors de certaines utilisations internes invisibles au lecteur et indépendantes des logiciels utilisés) car il ne permet pas l’interopérabilité sans convention préalable reconnue et acceptée à la fois par le lecteur et l’auteur de ces contenus. L’utilisation de telles étiquettes est plutôt réservée à d’autres usages spécifiques (et généralement locaux pour certains traitements internes) que la simple identification des langues.
Autres formats réservés d’étiquettes
Toute autre étiquette qui ne répond pas à un des formats ci-dessus ne doit pas être utilisée (même si elle répond à la syntaxe ABNF générale), car cela reste réservé pour le support éventuel de normes futures et leur intégration dans une mise à jour future de la recommandation BCP 47.
Utilisation
Les étiquettes d’identification de langues IETF permettent de faire référence à une langue ou une variété spécifique de cette langue, de catégoriser linguistiquement des données ou leur appliquer des traitements spécifiques (que ce soit pour la classification des contenus, leur rendu final, ou diverses transformations).
Leurs utilisations les plus connues en informatique sont les protocoles et standards de l’IETF (tels que HTTP, le courrier électronique et ses extensions MIME), du W3C (tels que HTML, XML, CSS), du Consortium Unicode (le standard Unicode lui-même dans ses bases de données normatives ou informative, ou le projet CLDR), ainsi que certains bureaux d’enregistrement de ces protocoles (dont les registres de noms de domaine pour l’internationalisation des noms de domaine), et les standards de langages informatiques (notamment ceux de l’ANSI et d’Ecma International).
L’ISO a développé des normes ISO 639, ISO 3166 et ISO 15924 indépendantes avec d’autres objectifs que l’IETF (notamment en termes de stabilité de la codification, car ces normes ont d’autres usages que l’Internet et n’ont pas été initialement mises à jour en assurant la compatibilité ascendante pour les applications informatiques) ; mais les deux organismes travaillent désormais en concertation afin d’assurer l’interopérabilité (via la base d’enregistrement IANA des étiquettes de langue et un suivi des travaux mutuels, par bulletins d’information émis par les bureaux d’enregistrement des normes ISO, et la publication par l’IETF de RFC informatives, voire normatives en cas de mise à jour importante de la recommandation BCP 47). Ces normes ISO (datées) sont souvent préférées par les organismes publics de normalisation nationaux et internationaux (comme l’UIT, diverses agences de l’ONU, l’UPU) et pour l’usage bibliographique ou légal (en association avec une date de référence et de classification des contenus).
Alias synonymes et étiquettes préférées
Quand la précision de l’écriture n’est pas nécessaire pour une langue car c’est son système d’écriture préféré par défaut, le registre IANA ajoute un champ Suppress-Script:
dans l’enregistrement de la sous-étiquette de langue et qui mentionne alors la sous-étiquette de cette écriture : cela crée des alias pour toutes les étiquettes indiquant à la fois cette langue et cette écriture (et toute variété régionale ou variante de cette langue) vers l’étiquette préférée sans mention de la sous-étiquette d’écriture. Toutefois, des exceptions peuvent être faites pour certaines variétés régionales, elles sont incluses dans le registre dans un enregistrement supplémentaire de Type:Tag
, relatif à l’étiquette complète mentionnant à la fois la langue et la région.
Les alias synonymes mentionnés dans la section suivante à titre d’exemples ne sont pas exhaustifs : le jeu complet d'alias pour chaque langue peut être déduit des données du registre IANA, qui mentionne les éventuelles étiquettes ou sous-étiquettes dépréciées (mais toujours valides) et leur associe éventuellement une étiquette ou sous-étiquette préférée (par un champ Preferred:
ajouté dans l’enregistrement de l’étiquette ou la sous-étiquette redéfinie comme alias).
Exemples
- fr : français (moderne), a priori écrit dans l'alphabet latin, car cette écriture est indiquée par défaut dans le registre IANA, dans n’importe laquelle de ses variétés régionales ou internationales (également les alias « fr-Latn », « fra » et « fre », définis comme synonymes non recommandés). Note : le français cajun et la plupart des créoles fondés sur le français sont identifiables séparément.
- fr-BE : français de Belgique, a priori écrit dans l'alphabet latin. Note : le wallon est identifiable séparément.
- fr-CA : français du Canada
- fr-FR : français de France, a priori écrit dans l'alphabet latin, dans n’importe laquelle de ses variétés régionales non normalisées séparément. Note : le picard est identifiable séparément.
- be-cyrl : biélorusse écrit en alphabet cyrillique (noter que « be » signifie ici « biélorusse » et non pas « Belgique »).
- eo : espéranto écrit dans l'alphabet latin (y compris les caractères accentués spécifiques).
- ht : créole haïtien. Note : cette étiquette est différente de « fr-HT » qui désigne le français standard parlé à Haïti et non le créole plus commun (souvent difficile à comprendre pour un francophone non natif d’Haïti).
- hy-arevela : arménien oriental, a priori écrit dans l’alphabet arménien.
- ja : japonais, a priori écrit en sinogrammes kanji et/ou syllabaires kana (hiragana et/ou katakana) (également l'alias « ja-Jpan », défini comme synonyme car cette triple écriture est indiquée par défaut dans le registre IANA).
- ja-Hrkt : japonais, écrit avec les syllabaires kana (sans sinogrammes kanji).
- ja-Latn : japonais, transcrit dans l’alphabet latin dans n’importe quel système de romanisation.
- ja-Latn-hepburn : japonais, transcrit dans l’alphabet latin en utilisant la méthode Hepburn traditionnelle[5].
- ja-Latn-hepburn-heploc[6],[7] : japonais, transcrit dans l’alphabet latin en utilisant la méthode Hepburn modifiée. Cependant l'IANA déconseille son utilisation et recommande plutôt d'utiliser ja-Latn-alalc97[8],[9].
- ncs : langue des signes du Nicaragua (également l’alias « sgn-NI », défini comme synonyme, déprécié et non recommandé).
- sr : serbe (peut être écrit dans l’alphabet latin et/ou l’alphabet cyrillique, voire transcrit dans d’autres « écritures », y compris l’alphabet Braille cyrillique et le sous-ensemble alphabétisé d’une langue des signes, ou dans une forme orale ou une transcription phonétique).
- sr-Latn : serbe, écrit dans l’alphabet latin.
- sr-Latn-fonapi : serbe, écrit dans l’alphabet latin, en transcription phonétique internationale.
- sr-Cyrl : serbe, écrit dans l’alphabet cyrillique.
- zh : chinois de n'importe quel région ou pays, à priori écrit en sinogrammes simplifiés (« Hans »), car cette écriture est indiquée par défaut dans le registre IANA.
- yue : chinois cantonais, a priori écrit en sinogrammes traditionnels, car cette écriture est indiquée par défaut dans le registre IANA (également l’alias « zh-yue », défini comme synonyme non recommandé).
- cmn : chinois mandarin (également les alias « zh-cmn » et « zh-guoyu », définis comme synonymes non recommandés).
- zh-Latn : chinois de n'importe quel région ou pays, transcrit dans l’alphabet latin dans n’importe quel système de romanisation
- zh-Latn-pinyin : chinois de n'importe quel région ou pays, transcrit dans l’alphabet latin avec le système de romanisation pinyin.
- zh-Hant : chinois de n'importe quel région ou pays, écrit en sinogrammes traditionnels.
- cmn-Hant-TW : chinois mandarin de Taïwan, écrit en sinogrammes traditionnels.
Notes et références
Notes
Références
- ↑ (en) « Tags for Identifying Languages », Request for comments no 5646,
- ↑ (en) « Tags for Identifying Languages », Request for comments no 4646,
- ↑ (en) « septembre 2006 », Request for comments no 4647
- ↑ (en) Registre IANA des composants d’étiquettes de langue IETF.
- ↑ (en) https://www.iana.org/assignments/lang-subtags-templates/hepburn.
- ↑ (en) https://www.iana.org/assignments/lang-subtags-templates/heploc.
- ↑ (en) https://www.ietf.org/assignments/lang-subtags-templates/heploc-20100209.
- ↑ (en) https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry.
- ↑ (en) http://www.alvestrand.no/pipermail/ietf-languages/2009-December/009822.html.
Voir aussi
Articles connexes
- Code de langue
- Best Current Practice
- Request for comments
- Langue (métadonnée)
- Négociation du contenu
Liens externes
- (en) BCP 47 Language Tags
- (en) RFC 5646 Tags for Identifying Languages
- (en) RFC 4647 Matching of language tags
- (fr) RFC 4646
- (fr) RFC 4647
- (fr) RFC 5646: Tags for Identifying Languages
- (fr) RFC 4647: Matching of language tags
- (en) Language tags in HTML and XML
- (en) http://www.langtag.net/
- (en) Language Tag Registry Update Working Group