Internet, le 8 janvier 2008,
Ce document qui est une traduction du document RFC 4647 de l'IETF (Internet Engineering Task Force) peut comporter des erreurs ou en introduire de nouvelles. Seul le document original à ftp://ftp.rfc-editor.org/in-notes/rfc4647.txt fait référence.
La traduction est disponible sous licence Creative Commons (http://creativecommons.org/licenses/by/2.0/fr/)
Traduit par Jean-Jacques Solari et relu par Claude Briere de l'Isle.

RFC 4647

Network Working Group                             A. Phillips, rédacteur
Document RFC : 4647 (errata)                                 Yahoo! Inc.
Document BCP : 47                                    M. Davis, rédacteur
Remplace     : 3066                                               Google
Catégorie    : Best Current Practice                      Septembre 2006

La correspondance des étiquettes de langues

Statut de ce mémoire

Ce document recueille les pratiques exemplaires Internet courantes de la communauté Internet, et il appelle le débat et des suggestions d'amélioration. La distribution de ce mémoire est libre.

Notice de droits d'auteur

Copyright (C) The Internet Society (2006).

Résumé

Ce document décrit une syntaxe appelée un choix de langues (language-range) pour définir les éléments dans la liste des préférences de langues d'un utilisateur. Il décrit également plusieurs mécanismes pour les comparer et les associer à des étiquettes de langues. Deux type de mécanismes de correspondance sont définis : le filtrage (filtering) et la consultation (lookup). Le filtrage produit un ensemble (éventuellement vide) d'étiquettes de langues tandis que la consultation produit une seule étiquette de langue. Les applications possibles comprennent la négociation de langue ou la sélection de contenu. Ce document, couplé au document RFC 4646, remplace le document RFC 3066, lequel remplaçait le document RFC 1766.

Table des matières

1. Introduction

Depuis toujours, les êtres humains sur la planète utilisent nombre de langues. Il y a beaucoup de raisons à vouloir identifier la langue utilisée lors d'une présentation ou d'une demande d'informations.

Les applications, les protocoles ou les spécifications utilisant des identificateurs de langues, telles que les étiquettes de langues définies dans le document [RFC4646], ont parfois besoin d'associer les étiquettes de langues aux préférences de langues de l'utilisateur.

Ce document définit une syntaxe (dite un choix de langue, cf. la section 2) pour définir les éléments dans la liste des préférences de langues d'un utilisateur (dite la liste de priorité des langues, cf. la section 2.3), ainsi que plusieurs schémas de sélection ou de filtrage d'ensembles d'étiquettes de langues par comparaison des étiquettes de langues aux préférences de l'utilisateur. Les applications, protocoles ou spécifications ont des besoins et des exigences variées qui affecteront la sélection d'un schéma de correspondance adapté.

Ce document décrit comment indiquer les préférences d'un utilisateur au moyen de choix de langues, de trois schémas de correspondance de ces choix à un ensemble d'étiquettes de langues, et de diverses considérations pratiques concernant la mise en œuvre et l'utilisation de ces schémas.

Ce document, couplé au document [RFC4646], remplace le document [RFC3066], lequel remplaçait le document [RFC1766].

Les mots-clés « DOIT », « NE DOIT PAS », « OBLIGATOIRE », « DEVRA », « NE DEVRA PAS », « DEVRAIT », « NE DEVRAIT PAS », « PEUT  » et « OPTIONNEL » dans ce document doivent s'interpréter comme décrit dans le [RFC2119].

2. Le choix de langues

Les étiquettes de langues [RFC4646] aident à identifier des langues, qu'elles soient parlées, écrites, par signes ou signalées autrement, pour des besoins de communication. Les applications, protocoles ou spécifications utilisant des étiquettes de langues sont souvent confrontés au problème d'identifier des blocs de contenu qui partagent certains attributs de langues. Par exemple, le protocole HTTP/1.1 [RFC2616] décrit un mécanisme de ce genre dans sa description de l'en-tête Accept-Language (section 14.4), qui est utilisé pour sélectionner un contenu sur un serveur en fonction de la langue de ce contenu.

Il est donc utile de disposer d'un mécanisme pour identifier des ensembles d'étiquettes de langues partageant des attributs spécifiques. Cela permet aux utilisateurs de sélectionner ou filtrer les étiquettes de langues en fonction d'exigences spécifiques. Un tel identificateur est appelé un choix de langues (language range).

Il existe plusieurs types de choix de langues, dont les attributs spécifiques varient selon leur application. Les choix de langues sont similaires aux étiquettes de langues : ils se composent d'une séquence de sous-étiquettes, séparées par des traits d'union. Dans un choix de langues, chaque sous-étiquette DOIT être une séquence de caractères alphanumériques ASCII, ou bien le seul caractères '*' (%x2A, ASTÉRISQUE). Le caractère '*' est un « joker » (wildcard) qui correspond à n'importe quelle séquence de sous-étiquettes. La signification et l'utilisation des jokers varient selon le type de choix de langues.

Le traitement des étiquettes de langues et donc des choix de langues est indépendant de la casse : il existe des conventions pour la capitalisation des sous-étiquettes mais on NE DOIT PAS leur prêter de signification. La correspondance des étiquettes de langues et des choix de langues DOIT avoir lieu indépendamment de la casse.

2.1. Le choix de langues élémentaire

Un choix de langues élémentaire (basic language range) a la même syntaxe qu'une étiquette de langue [RFC3066] ou est constitué du seul caractère "*". Le choix de langue élémentaire a d'abord été décrit par le protocole HTTP/1.1 [RFC2616] puis par le [RFC3066]. Voici sa définition ABNF [RFC4234] :

   language-range   = (1*8ALPHA *("-" 1*8alphanum)) / "*"
   alphanum         = ALPHA / DIGIT

Un choix de langue élémentaire diffère des étiquettes de langues définies dans le [RFC4646] seulement par la non-obligation d'être bien formé ou validé d'après le registre des sous-étiquettes de langues de l'IANA. Notez que la définition ABNF [RFC4234] dans le [RFC2616] est inexacte, puisqu'elle n'admet l'utilisation de chiffres nulle part dans la production 'language-range' (cf. l'errata [RFC2616errata]).

2.2. Le choix de langues étendu

À l'occasion, les utilisateurs souhaiteront sélectionner un jeu de langues en fonction de la présence de sous-étiquettes spécifiques. Un choix de langues étendu (extended language range) décrit les préférences de langues d'un utilisateur comme une séquence ordonnée de sous-étiquettes. Par exemple, l'utilisateur peut vouloir sélectionner toutes les étiquettes de langues contenant la sous-étiquette de région 'CH' (Suisse). Les choix de langues étendus sont utiles pour indiquer la séquence particulière de sous-étiquettes qui apparaît dans l'ensemble des étiquettes correspondantes sans avoir à définir toutes les sous-étiquettes intermédiaires.

Un choix de langues étendu peut être représenté par la définition ABNF suivante :

   extended-language-range = (1*8ALPHA / "*")
                             *("-" (1*8alphanum / "*"))

La sous-étiquette joker '*' peut apparaître à n'importe quelle position dans le choix de langues étendu, où elle correspond à toute séquence de sous-étiquettes susceptible d'apparaître à cette position dans une étiquette de langues. Par contre, les jokers ailleurs qu'en première position sont ignorés par le filtrage étendu (cf. la section 3.2.2). L'utilisation ou l'absence d'un (ou plusieurs) joker n'impliquent pas qu'un certain nombre de sous-étiquettes apparaîtront dans l'ensemble correspondant d'étiquettes de langues.

2.3. La liste de priorité des langues

Les préférences de langues d'un utilisateur devront souvent indiquer plusieurs choix de langue, et les utilisateurs doivent donc souvent définir une liste prioritaire de choix de langues pour refléter au mieux leurs préférences de langues. Cela est particulièrement vrai des locuteurs de langues minoritaires. Un locuteur du breton en France, par exemple, peut indiquer "br" suivi de "fr", qui signifie une préférence du breton si disponible, sinon du français en meilleure alternative. Cela peut devenir plus complexe : un autre utilisateur peut vouloir se rabatre du same skolt au same du Nord puis au finnois.

Une liste de priorité des langues (language priority list) est une liste de choix de langues prioritaire ou à coefficient (weighted). Un exemple bien connu d'une telle liste est celui de l'en-tête "Accept-Language" défini dans le RFC 2616 [RFC2616] (cf. la section 14.4) et le RFC 3282 [RFC3282].

Les diverses opérations de correspondance décrites dans ce document incluent les facteurs d'utilisation d'une liste de priorité des langues. Ce document ne définit pas la syntaxe d'une liste de priorité des langues ; la définiton d'une telle syntaxe est de la responsabilité du protocole, de l'application ou de la spécification qui l'utilisent. Dans les exemples données dans ce document, les listes de priorité des langues apparaîtront comme une séquence de choix entre guillemets doubles, séparés par des virgules comme ceci : "en, fr, zh-Hant" (qui se lit « anglais avant français avant chinois dans une écriture traditionnelle »).

Une liste de choix simple est censée en ordre décroissant de priorité. D'autres listes de priorité des langues prévoient des « coefficients qualitatifs » (quality weights) pour les choix de langues afin d'indiquer la priorité relative des préférences de langues de l'utilisateur. Un exemple en est l'utilisation des valeurs "q" dans la syntaxe de l'en-tête "Accept-Language" (défini dans le [RFC2616], section 14.4, et dans le [RFC3282]).

3. Les types de correspondance

L'association des choix de langues aux étiquettes de langues peut être réalisée de plusieurs façons différentes. Cette section décrit trois schémas de correspondance ainsi que les facteurs à prendre en compte pour effectuer une sélection entre eux. Les protocoles et les spécifications prétendant à une conformité avec cette spécification DOIVENT clairement indiquer le mécanisme utilisé pour sélectionner ou associer les étiquettes de langues.

Il y a deux types de schémas de correspondance dans ce document. Un schéma de correspondance qui produit zéro ou plus étiquettes de langues correspondantes est dit de filtrage (filtering). Un schéma de correspondance qui produit exactement une seule correspondance pour une requête donnée est dit de consultation (lookup).

3.1. La sélection d'un schéma de correspondance

Les applications, protocoles et spécifications doivent décider quel type de correspondance utiliser. Parfois, des méthodes de correspondance différentes conviennent à d'autres types de traitement au sein d'une application ou d'un protocole particuliers.

Ce document décrit trois schémas de correspondance :

  1. 1. Le filtrage élémentaire (section 3.3.1) compare une liste de priorité des langues composée de choix de langues élémentaires (section 2.1) à des ensembles d'étiquettes de langues.
  2. 2. Le filtrage étendu (section 3.3.2) compare une liste de priorité des langues composée de choix de langues étendus (section 2.2) à des ensembles d'étiquettes de langues.
  3. 3. La consultation (section 3.4) compare une liste de priorité des langues composée de choix de langues élémentaires à des ensembles d'étiquettes de langues afin de trouver l'étiquette de langue exacte qui correspond le mieux au choix.

Le filtrage peut être utilisé pour produire un ensemble de résultats (telle qu'une collection de documents) en comparant les préférences de l'utilisateur à un ensemble d'étiquettes de langues. Par exemple, lors d'une recherche, on peut utiliser le filtrage pour limiter les résultats aux éléments étiquetés en français. On peut aussi utiliser le filtrage pour décider si l'on doit effectuer un processus dépendant de la langue sur un contenu. Par exemple, un processus pourrait afficher en italiques les paragraphes dans un document dont l'étiquette de langue correspond au choix de langue "nl" (hollandais).

La consultation produit le seul résultat qui correspond le mieux aux préférences de l'utilisateur dans la liste des étiquettes disponibles, elle est donc utile dans les cas où un seul élément est nécessaire (et pour lesquels il ne peut être retourné qu'un seul élément).

Par exemple, si un processus devait insérer un message d'erreur en lecture humaine dans un en-tête de protocole, il pourrait sélectionner le texte en fonction de la liste de priorité des langues de l'utilisateur. Puisque le processus ne peut retourner qu'un seul élément, il est forcé d'en retenir un seul et il doit retourner un élément, même si aucune des étiquettes de langues du contenu ne correspond à la liste de priorité des langues fournie par l'utilisateur.

3.2. Observations concernant la mise en œuvre

La correspondance des étiquettes de langues est un outil et elle ne définit pas en soi de procédure complète d'utilisation des étiquettes de langues. De telles procédures sont intimement liées au protocole d'application où elles apparaissent. Lors de la définition d'une opération de protocole utilisant une comparaison, le protocole DOIT indiquer :

Les applications, protocoles et spécifications ne sont pas obligées de valider ou d'interpréter la sémantique des étiquettes de langues ou choix de langues, ou des sous-étiquettes contenues, ni n'ont besoin d'accéder au registre des sous-étiquettes de langues IANA (Language Subtag Registry), cf.la section 3 dans le [RFC4646]). Cela simplifie la mise en œuvre.

En revanche, les concepteurs d'applications, de protocoles ou de spécifications sont invités à utiliser les informations du registre des sous-étiquettes de langues IANA pour effectuer la canonisation des étiquettes de langues et choix de langues afin de lier les étiquettes ou sous-étiquettes exonérées et obsolètes à leurs équivalents modernes.

Les applications, protocoles ou spécifications canonisant les choix de langues DOIVENT effectuer les opérations de correspondance avec la forme canonique et la forme originale (non modifiée) du choix de langues, ou bien DOIVENT canoniser aussi chaque étiquette pour la comparaison.

Notez que la canonisation des choix de langues rend certaines opérations impossibles. Par exemple, une mise en œuvre qui canonise le choix de langues "art-lojban" (langage artificiel, variante lojban) pour utiliser le plus moderne "jbo" (lojban) ne peut pas servir pour sélectionner seulement les éléments avec l'ancienne étiquette.

Les applications, protocoles ou spécifications utilisant des choix de langues élémentaires peuvent recevoir parfois des choix de langues étendus à la place. L'application, le protocole ou la spécification DOIVENT opter entre a) associer les choix de langues étendus à des choix de langues élémentaires en utilisant l'algorithme décrit plus loin, b) rejeter tous les choix de langues étendus dans la liste de priorité de langue qui ne sont pas des choix de langues élémentaires valides, ou c) traiter chaque choix de langues étendu comme s'il s'agissait d'un choix de langues élémentaire, ce qui aura le même effet que de les ignorer, puisque ces choix ne correspondront pas à des étiquettes de langues valides.

Voici comment associer un choix de langues étendu à un choix de langues élémentaire : si la première sous-étiquette est le caractère '*', alors le choix entier est traité comme "*", sinon chaque sous-étiquette joker est supprimée. Par exemple, le choix de langues étendu "en-*-US" correspond à "en-US" (anglais des États-Unis).

Les applications, protocoles ou spécifications, en répondant à leurs exigences particulières, peuvent offrir des options de prétraitement ou de configuration. Par exemple, la mise en œuvre peut laisser un utilisateur associer ou lier (map) un choix de langues particulier à une valeur différente. Cet utilisateur peut vouloir associer les sous-étiquettes de choix de langues 'nn' (norvégien nynorsk) et 'nb' (norvégien bokmal) à la sous-étiquette plus générale 'no' (norvégien). Ou il veut peut-être associer les requêtes du choix "zh-Hans" (chinois en écriture simplifiée) à un contenu portant l'étiquette de langue "zh-CN" (chinois utilisé en Chine, où l'écriture simplifiée prédomine). Une documentation sur la façon dont les choix ou les étiquettes sont altérés, triés (prioritized) ou comparés dans la correspondance suivante aidera les utilisateurs de cette mise en œuvre à réaliser ce type de configuration.

3.3. Le filtrage

Le filtrage est utilisé pour sélectionner l'ensemble des étiquettes de langues qui correspondent à une liste de priorité des langues donnée. On l'appelle filtrage parce que cet ensemble est susceptible de ne contenir aucun élément du tout ou de retourner un nombre arbitrairement grand d'éléments correspondants : autant d'éléments correspondant à la liste de priorité des langues, en « filtrant » les éléments qui ne correspondent pas.

Dans le filtrage, chaque choix de langues représente l'étiquette de langue la moins spécifique (c'est-à-dire l'étiquette de langue avec le moins de sous-étiquettes) constituant une correspondance acceptable.

Toutes les étiquettes de langues dans l'ensemble de correspondance d'étiquettes auront un nombre de sous-étiquettes égal ou supérieur à celui du choix de langues. Chaque sous-étiquette non-joker dans le choix de langues apparaîtront dans chacune des étiquettes de langues correspondantes. Par exemple, si la liste de priorité des langues se compose de "de-CH" (allemand utilisée en Suisse), on pourrait voir des étiquettes telles que "de-CH-1996" (allemand utilisé en Suisse, orthographe de 1996) mais on ne verra jamais l'étiquette "de" (puisqu'il manque la sous-étiquette 'CH').

Si la liste de priorité des langues (cf. la section 2.3) contient plusieurs choix, le contenu retourné est généralement ordonné par ordre décroissant de préférence, mais il PEUT ne pas être ordonné, en fonction des besoins de l'application ou du protocole.

Voici quelques exemples d'applications où le filtrage peut se révéler approprié :

Le filtrage semble impliquer l'existence d'une relation sémantique entre les étiquettes de langues partageant le même préfixe. Bien que ce soit souvent le cas, ce n'est pas toujours vrai : les étiquettes de langues qui correspondent à un choix de langues spécifique ne représentent pas forcément des langues mutuellement intelligibles.

3.3.1. Le filtrage élémentaire

Le filtrage élémentaire compare des choix de langues élémentaires à des étiquettes de langues. Chaque choix de langues élémentaire dans la liste de priorité des langues est examiné à son tour en ordre de priorité. Un choix de langues correspond à une étiquette de langue particulière si, dans une comparaison indépendante de la casse, il est égal exactement à l'étiquette, ou s'il est égal exactement au préfixe de l'étiquette tel que le premier caractère après le préfixe soit un trait d'union "-". Par exemple, le choix de langues "de-de" (allemand utilisé en Allemagne) correspond à l'étiquette de langue "de-DE-1996" (allemant utilisé en Allemagne, orthographe de 1996), mais pas aux étiquettes de langues "de-Deva" (allemand en écriture devanagari) ni "de-Latn-DE" (allemand, en écriture latine, utilisé en Allemagne).

Le choix spécial "*" dans une liste de priorité des langues correspond à toute étiquette. Un protocole utilisant les choix de langues PEUT définir des règles supplémentaires pour la sémantique de "*" ; par exemple, le protocole HTTP/1.1 [RFC2616] définit que le choix "*" correspond seulement aux langues non associées par un autre choix dans un en-tête "Accept-Language".

Le filtrage élémentaire est identique au type d'association décrit dans le [RFC3066], section 2.5 (Le choix de langues).

3.3.2. Le filtrage étendu

Le filtrage étendu compare des choix de langues étendus à des étiquettes de langues. Chaque choix de langues étendu dans la liste de priorité des langues est examiné à son tour en ordre de priorité. Un choix de langues correspond à une étiquette de langue particulière si chaque liste respective de sous-étiquettes correspond. Pour déterminer une correspondance :

  1. 1. Découper le choix de langues étendu et l'étiquette de langue à comparer en une liste de sous-étiquettes en effectuant les coupures aux caractères traits d'union (%x2D). Deux sous-étiquettes correspondent si celles-ci sont les mêmes dans une comparaison indépendante de la casse, ou bien si la sous-étiquette du choix de langues est le joker '*'.
  2. 2. Commencer par la première sous-étiquette dans chaque liste. Si la première sous-étiquette dans le choix ne correspond pas à la première dans l'étiquette, la correspondance échoue dans son ensemble. Sinon, passer aux sous-étiquettes suivantes dans le choix et l'étiquette.
  3. 3. Tant qu'il reste des sous-étiquettes dans la liste du choix de langues :
  4. 4. Lorsque la liste du choix de langues n'a plus de sous-étiquettes, la correspondance réussit.

Les sous-étiquettes non définies, y compris celles à la fin du choix de langues, sont de ce fait traitées comme si on leur avait affecté la valeur joker '*'. Tout comme le filtrage élémentaire, le filtrage étendu sélectionne un contenu avec des étiquettes de longueur quelconque partageant les mêmes sous-étiquettes initiales que le choix de langues. En outre, le filtrage étendu sélectionne les étiquettes de langues contenant des sous-étiquettes intermédiaires non indiquées dans le choix de langues. Par exemple, le choix de langues étendu "de-*-DE" (ou son synonyme "de-DE") correspond à toutes les étiquettes suivantes :

Le même choix ne correspond à aucune des étiquettes suivantes pour les raisons indiquées :

Remarque : Le [RFC4646] définit chaque type de sous-étiquette (de langue, d'écriture, de région, etc.) selon la position, la dimension et le contenu. Cela signifie que les sous-étiquettes dans un choix de langues ne peuvent correspondre qu'à des types spécifiques de sous-étiquettes dans une étiquette de langue. Par exemple, une sous-étiquette telle que 'Latn' est toujours une sous-étiquette d'écriture (à moins de suivre un singleton) tandis qu'une sous-étiquette telle que 'nedis' ne peut correspondre qu'à la sous-étiquette de variante équivalente. Les sous-étiquettes de deux lettres en position initiale ont un type différent (langue) que les sous-étiquettes de deux lettres en position suivante (région). C'est la raison pour laquelle un joker dans le choix de langues étendu est significatif en première position mais ignoré ailleurs.

3.4. La consultation

La consultation est utilisée pour sélectionner la seule étiquette de langue correspondant le mieux à la liste de priorité des langues pour une requête donnée. Lors d'une consultation, chaque choix de langues dans la liste de priorité des langues est examiné à son tour en ordre de priorité. En opposition avec le filtrage, chaque choix de langues représente l'étiquette la plus spécifique constituant une correspondance acceptable. La première étiquette correspondante trouvée, selon la priorité de l'utilisateur, est censée la meilleure correspondance et l'élément est retourné. Par exemple, si le choix de langues est "de-ch", une action de consultation peut produire un contenu avec les étiquettes "de" ou "de-CH", mais jamais un contenu avec l'étiquette "de-CH-1996". Si aucune étiquette de langue ne correspond à la demande, la valeur "default" est retournée.

Par exemple, si une application insère du contenu dynamique dans un document, en retournant une chaîne vide s'il n'y a aucune correspondance exacte, ce n'est pas une option. À la place, l'application « se replie » (fall back) jusqu'à ce qu'elle trouve une étiquette de langue correspondante associée à un bloc de contenu approprié à insérer. Quelques applications de consultation comprennent :

Dans le schéma de consultation, le choix de langues est tronqué progressivement à partir de la fin jusqu'à ce qu'une étiquette de langue correspondante soit trouvée. Les sous-étiquettes d'une seule lettre ou d'un seul chiffre (y compris la lettre 'x', qui introduit les séquences d'utilisation privée, et les sous-étiquettes qui introduisent les extensions) sont supprimées en même temps que leur sous-étiquette de queue (trailing subtag) la plus proche. Par exemple, en commençant avec le choix "zh-Hant-CN-x-private1-private2" (chinois, écriture traditionnelle, Chine, deux sous-étiquettes d'utilisation privée), la consultation recherche progressivement du contenu comme indiqué ci-dessous :

    Exemple d'un schéma de repli de consultation

   Choix à réaliser : zh-Hant-CN-x-private1-private2
   1. zh-Hant-CN-x-private1-private2
   2. zh-Hant-CN-x-private1
   3. zh-Hant-CN
   4. zh-Hant
   5. zh
   6. (default)

Le comportement de repli autorise de la flexibilité dans la recherche d'une correspondance. Sans repli, le contenu par défaut serait immédiatement retourné si un contenu correspondant exact n'était pas disponible. Avec un repli, un résultat correspondant mieux à la demande de l'utilisateur peut être fourni.

Les sous-étiquettes d'extensions et celles d'utilisation privée non reconnues peuvent n'être pas liées à une application particulière de consultation. Comme ces sous-étiquettes viennent à la fin de la séquence de sous-étiquettes, elles sont supprimées les premières au cours du processus de repli et ne constituent généralement pas une barrière à l'interopérabilité. Toutefois, une application PEUT les supprimer des choix préalablement à la consultation (à condition que la mise en œuvre les supprime aussi des étiquettes à comparer). Cette modification a lieu au sein de la mise en œuvre, et les applications, protocoles ou spécifications NE DEVRAIENT PAS supprimer ou modifier les sous-étiquettes dans un contenu qu'ils retournent ou transmettent, car cela supprime des informations utilisables ailleurs.

Le choix de langues spécial "*" correspond à toute étiquette de langue. Dans le schéma de consultation, ce choix ne comporte pas suffisamment d'information en soi pour déterminer quelle étiquette de langue est la plus appropriée, puisque qu'il correspond à n'importe laquelle. Si le choix de langues "*" est suivi d'autres choix de langues, il est sauté. Si le choix de langues "*" est seul dans la liste de priorité des langues, ou si aucun autre choix de langues ne le suit, la valeur par défaut est calculée et retournée.

Dans certains cas, la liste de priorité des langues peut contenir un ou plusieurs choix de langues (par exemple, lorsque la même liste de priorité des langues est utilisée en entrée à la fois pour la consultation et le filtrage). Les valeurs jokers dans un choix de langues étendu correspondent normalement à toute valeur susceptible d'apparaître à cette position dans une étiquette de langue. Puisqu'un seul élément uniquement peut être retourné pour une requête de consultation donnée, les jokers dans un choix de langues doivent être traités de manière logique ou bien la même requête produira des résultats très variés. Les applications, protocoles ou spécifications acceptant les choix de langues étendus DOIVENT définir quel élément est retourné lorsque plusieurs éléments correspondent au choix de langues étendu.

Par exemple, une mise en œuvre pourrait associer les choix de langues étendu aux choix élémentaires. Une autre possibilité serait que la mise en œuvre retourne la première étiquette correspondante dans l'ordre ASCII. Si le choix de langues était "*-CH" ('CH' représente la Suisse) et l'ensemble d'étiquettes comprenait "de-CH" (allemand utilisé en Suisse), "fr-CH" (français utilisé en Suisse) et "it-CH" (italien utilisé en Suisse), l'étiquette "de-CH" serait alors retournée.

3.4.1. Les valeurs par défaut

Chaque application, protocole ou spécification utilisant la consultation DOIT définir le comportement par défaut lorsqu'aucune étiquette ne correspond à la liste de priorité des langues. La teneur de cette action dépend fortement de la façon dont s'applique la consultation. Voici quelques exemples de comportements par défaut :

Lors d'une consultation utilisant une liste de priorité des langues, l'examen progressif DOIT traiter chaque choix de langues dans la liste avant de chercher ou calculer la valeur par défaut.

La valeur par défaut PEUT être calculée ou inclure une recherche ou une correspondance supplémentaires. Les applications, protocoles ou spécifications peuvent définir des méthodes différentes où les utilisateurs peuvent indiquer ou passer outre les valeurs par défaut.

Une méthode courante de pourvoir une valeur par défaut est de laisser paramétrer un choix de langues spécifique par défaut pour un type spécifique de requête. Si c'est l'approche suivie, ce choix de langues DOIT être traité comme s'il était ajouté à la fin de la liste de priorité des langues dans son ensemble plutôt qu'après chaque élément dans la liste. L'application, le protocole ou la spécification DOIVENT aussi définir le comportement par défaut si cette recherche échouait à trouver une étiquette ou un élément correspondants.

Par exemple, si la liste de priorité des langues d'un utilisateur particulier est "fr-FR, zh-Hant" (français utilisé en France suivi de chinois dans l'écriture traditionnelle) et que le programme de correspondance a un choix de langues par défaut de "ja-JP" (japonais utilisé au Japon), alors la recherche par le programme est la suivante :

   1. fr-FR
   2. fr
   3. zh-Hant // langue suivante
   4. zh
   5. ja-JP   // recherche du contenu par défaut
   6. ja
   7. (valeur par défaut définie par la mise en œuvre)

4. Autres facteurs

En travaillant avec les choix de langues et les schémas de correspondance, d'autres points peuvent influencer la sélection de l'un ou l'autre schémas.

4.1. La sélection des choix de langues

Les utilisateurs indiquent leurs préférences de langues via la sélection d'un choix de langues ou via la liste des choix de langues dans une liste de priorité des langues. Le type de correspondance affecte ce qu'est le meilleur choix pour un utilisateur.

La plupart des schémas de correspondance n'essayent pas de traiter la signification sémantique des sous-étiquettes. Le choix de langues est comparé, indépendamment de la casse, à chaque étiquette de langue examinée, au moyen d'une manipulation de chaîne élémentaire. Les utilisateurs DEVRAIENT sélectionner les choix de langues qui sont des étiquettes de langues bien formées valides selon le [RFC4646] (en substituant au besoin les jokers dans les choix de langues étendus).

Les applications sont invitées à canoniser les étiquettes et les choix de langues en utilisant le champ 'Preferred-Value' des étiquettes ou sous-étiquettes caduques (deprecated) du registre des sous-étiquettes de langues IANA (Language Subtag Registry). Si l'utilisateur travaille avec un contenu susceptible d'utiliser la forme ancienne, il peut inclure l'ancienne et la nouvelle forme dans une liste de priorité des langues. Par exemple, l'étiquette "art-lojban" est caduque. La sous-étiquette 'jbo' est censée la remplacer, l'utilisateur peut donc l'utiliser pour former le choix de langues. Ou bien il peut les inclure toutes deux dans une liste de priorité des langues : "jbo, art-lojban".

Les utilisateurs DEVRAIENT éviter les sous-étiquettes qui n'ajoutent aucune valeur distinctive à un choix de langues. Dans un filtrage, moins le choix de langues comprend de sous-étiquettes, plus grand le contenu probable qui lui correspondra, tandis que dans une consultation les sous-étiquettes superflues écarteront peut-être un meilleur contenu plus spécifique en faveur d'un contenu qui l'est moins. Par exemple, le choix "de-Latn-DE" retourne un contenu étiqueté "de" au lieu d'un conteu étiqueté "de-DE", même si ce dernier correspond probablement mieux.

Qu'une sous-étiquette ajoute une valeur distinctive peut dépendre du contexte de la requête. Par exemple, un utilisateur qui lit le chinois simplifié et le chinois traditionnel, toutefois préférant le simplifié, peut utiliser le choix "zh" pour un filtrage (correspondant à tous les éléments qu'il peut lire) mais "zh-Hans" pour une consultation (lui assurant d'obtenir la forme préférée si disponible tout en gardant un repli sur "zh"). D'un autre côté, le contenu ici devrait être étiqueté "zh-Hans" (ou "zh-Hant" si c'est le cas) pour le filtrage, tandis que pour la consultation, s'il y a un contenu "zh-Hans" ou bien un contenu "zh-Hant", l'un d'eux (celui considéré comme valant 'default') devrait également être rendu disponible avec le simple "zh". Notez que l'utilisateur peut créer une liste de priorité des langues "zh-Hans, zh" qui produit le meilleur résultat possible pour les deux schémas. Si l'utilisateur n'est pas sûr du schéma à utiliser (ou si plusieurs sont susceptibles de s'appliquer à une requête donnée), il DEVRAIT indiquer en premier le choix le plus spécifique (le plus grand nombre de sous-étiquettes) et fournir des préfixes plus courts ensuite dans la liste, pour assurer que le filtrage retourne un ensemble complet d'étiquettes.

Beaucoup de langues ont essentiellement une seule écriture. Celle-ci est normalement enregistrée dans le champ 'Suppress-Script' dans l'entrée de registre de la sous-étiquette de langue. Pour ces langues, les sous-étiquettes d'écritures NE DEVRAIENT PAS être utilisées pour former un choix de langues. De fait, le choix de langues "en-Latn" n'est pas approprié dans la plupart des cas (parce que la grande majorité des documents anglais sont en écriture latine, et donc la valeur du champ 'Suppress-Script' de la sous-étiquette de langue 'en' dans le registre est 'Latn').

Lorsqu'on travaille avec des étiquettes et des choix, notez que les sous-étiquettes d'extensions et la plupart de celles d'utilisation privée sont orthogonales à la correspondance des étiquettes de langues, en cela qu'elles définissent des attributs supplémentaires du texte non liés aux buts de la plupart des schémas de correspondance. Les utilisateurs DEVRAIENT éviter ces sous-étiquettes dans les choix de langues puisqu'elles interfèrent avec la sélection du contenu disponible. Utilisées dans les étiquettes de langues (par opposition aux choix), ces sous-étiquettes n'interfèrent pas normalement avec le filtrage (section 3), puisqu'elles apparaissent à la fin de l'étiquette et correspondront à tous les préfixes. Pour les mises en œuvre de consultation (section 3.4), on conseille d'ignorer les sous-étiquettes d'extensions et d'utilisation privée non reconnues lors du repli à une étiquette de langue.

4.2. La signification des étiquettes et des choix de langues

La sélection des étiquettes de langues en utilisant des choix de langues exige des utilisateurs de comprendre ce qu'ils sélectionnent. Les significations des diverses sous-étiquettes dans un choix de langues sont identiques à celles dans une étiquette de langue (cf. la section 4.2 dans le [RFC4646]), plus le joker "*" qui représente toute séquence de valeurs correspondantes.

4.3. Observations sur les sous-étiquettes d'utilisation privée

Un accord de gré à gré est nécessaire entre des parties qui prévoient d'utiliser ou d'échanger des étiquettes de langues contenant des sous-étiquettes d'utilisation privée. On DEVRAIT se montrer très prudent à employer des sous-étiquettes d'utilisation privée dans un contenu ou des protocoles prévus pour une utilisation générale. Les sous-étiquettes d'utilisation privée sont tout simplement inexploitables sans accord préalable pour échanger des informations.

La valeur et la signification sémantique des étiquettes d'utilisation privée et des sous-étiquettes utilisées en leur sein ne sont pas définies. Une correspondance d'étiquettes d'utilisation privée avec des choix de langues élémentaires ou étendus peut retourner un contenu imprévisible.

4.4. Observations sur la longueur des choix de langues

Les choix de langues ressemblent beaucoup aux étiquettes de langues pour ce qui est du contenu et de l'utilisation. Les types de restrictions applicables aux étiquettes de langues sont les mêmes que ceux applicables aux choix de langues. Cf. le [RFC4646] section 4.3 (Les facteurs de longueur).

5. Observations sur la sécurité

Les choix de langues utilisés dans une négociation de contenu peuvent servir à inférer la nationalité de l'émetteur et donc à identifier les cibles potentielles d'une surveillance. En outre, les choix de langues ou combinaisons de choix de langues uniques ou très inhabituels peuvent être utilisés pour suivre à la trace les activités d'un individu spécifique.

Il s'agit d'un cas particulier du problème général selon lequel tout ce qui est envoyé est visible de la partie réceptrice. Il faut être conscient que de telles préoccupations existent dans certains cas.

L'évaluation de l'ampleur exacte de la menace et des parades possibles est laissée à chaque application ou protocole.

6. Observations sur les jeux de caractères

Les étiquettes de langues n'admettent que les caractères A-Z, a-z, 0-9 et TRAIT D'UNION (%x2D). Les choix de langues utilisent aussi le caractère ASTÉRISQUE (%x2A). Ces caractères sont présents dans la plupart des jeux de caractères de sorte que la présentation ou l'échange des étiquettes de langues ou des choix de langues ne devraient pas être contraints par des problèmes relatifs aux jeux de caractères.

7. Références

7.1. Références normatives

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2277]
Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC4234]
Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4646]
Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.

7.2. Références informatives

[RFC1766]
Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC2616]
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616errata]
IETF, "HTTP/1.1 Specification Errata", October 2004, http://purl.org/NET/http-errata.
[RFC3066]
Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3282]
Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[XML10]
Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium Recommendation, February 2004, http://www.w3.org/TR/REC-xml.

Annexe A. Remerciements

Toute liste de contributeurs est forcément incomplète ; veuillez ne considérer la suivante que comme une sélection prise dans le groupe de personnes ayant contribué à faire de ce document ce qu'il est aujourd'hui.

Les contributeurs des RFC 3066 et RFC 1766, les précurseurs de ce document, ont énormément contribué à développer le mécanisme de correspondance des étiquettes de langues et, en particulier, le choix de langues élémentaire et le schéma de correspondance élémentaire. Ce document faisait à l'origine partie du [RFC4646], mais en fut détaché avant son achèvement. Ainsi, directement ou indirectement, les personnes citées dans le [RFC4646] avaient pris part au développement de ce document, et le travail effectué avant la scission est reconnu dans ce document.

Les personnes suivantes (en ordre alphabétique) ont participé à ce document ou aux RFC 1766 et 3066 :

Harald Alvestrand, Stephane Bortzmeyer, Jeremy Carroll, Peter Constable, John Cowan, Mark Crispin, Martin Duerst, Frank Ellermann, Doug Ewell, Debbie Garside, Marion Gunn, Jon Hanna, Kent Karlsson, Erkki Kolehmainen, Jukka Korpela, Ira McDonald, M. Patton, Randy Presuhn, Eric van der Poel, Markus Scherer, Misha Wolf, et beaucoup beaucoup d'autres.

Un très grand merci à Harald Tveit Alvestrand, qui à l'origine des RFC 1766 et 3066, et sans qui ce document n'aurait pas été possible.

Coordonnées des auteurs

Addison Phillips (rédacteur)
Yahoo! Inc.
EMail: addison@inter-locale.com
Mark Davis (rédacteur)
Google
EMail: mark.davis@macchiato.com ou mark.davis@google.com