Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

Extlang ou pas extlang ?

Première rédaction de cet article le 26 mai 2008


Le groupe de travail LTRU (Language Tag Registry Update) de l'IETF est très en retard dans son projet de normalisation des futures étiquettes de langue, ces courtes chaînes de caractères qui permettent d'indiquer la langue d'un document ou de préciser la langue qu'on souhaite utiliser sur Internet. Une des raisons de ce retard est le débat sans fin sur les « extlangs », ces mécanismes permettant de représenter le concept de « macrolangue » introduit par la norme ISO 639-3. En gros, l'égyptien doit-il se noter ar-arz ou bien arz ? Et le cantonais doit-il être zh-yue ou simplement yue ?

Dans la norme actuelle, le RFC 4646, les étiquettes de langue sont formées de plusieurs sous-étiquettes, chacune identifiant la langue, l'écriture ou le pays. Les sous-étiquettes qui identifient la langue sont tirées de ISO 639-1 ou ISO 639-2, normes qui placent toutes les langues sur un pied d'égalité.

Mais le monde des langues humaines est complexe. La définition traditionnelle d'une langue est le critère de compréhension mutuelle. Si différents que puissent être les accents, le vocabulaire et l'orthographe, l'anglais d'Australie peut être compris par un irlandais (parfois avec effort). C'est donc la même langue, dont la sous-étiquette est en. De même, si proches que soient le français et le catalan, par leur origine commune, deux locuteurs de ces deux langues ne peuvent pas se comprendre. Il s'agit donc bien de deux langues distinctes, dont les sous-étiquettes sont fr et ca.

Naturellement, il existe une zone grise : le danois est-il si différent du norvégien ? L'arabe marocain du tunisien ? Le cas est d'autant plus difficile que certaines langues sont différentes à l'oral mais moins à l'écrit (c'est justement le cas de l'arabe). D'une certaine façon, il n'existe qu'une langue arabe. D'une autre, il en existe plusieurs (qui ne recoupent pas forcément exactement les frontières nationales). Parfois, l'histoire ou la politique contribuent à brouiller la perception linguistique correcte, comme dans le cas du mandarin, souvent appelé chinois par abus de langage, parce que c'est la langue de l'État chinois.

Pour tenter de modéliser ce monde très complexe et qui n'a pas été conçu rationnellement, SIL, l'organisation qui a été la principale responsable de la norme ISO 639-3 a créé un nouveau concept, celui de macrolangue. Une macrolangue est une langue unique, selon certains critères, et un groupe de langues selon d'autres. Les deux plus célèbres sont le chinois (avec la sous-étiquette zh) et l'arabe (ar). Le registre d'ISO 639-3 indique donc pour chaque langue si elle est couverte par une macrolangue. Le cantonais est ainsi « couvert » par le chinois. Notons tout de suite que les langues couvertes (parfois appelées par dérision « microlangues ») ne sont pas des dialectes, ce sont bien des langues séparées, typiquement sans mutuelle compréhensibilité.

Comment représenter les macrolangues dans le successeur du RFC 4646 ? La première idée, dont les prémisses figurent dans le RFC 4646, était d'utiliser un concept nouveau, l'Extended Language Subtag, l'extlang. Dans ce système, tel que prévu à l'origine, la première sous-étiquette identifiait la macrolangue (ou la langue tout court pour les cas - les plus fréquents - où il n'y avait pas de macrolangue) et un ou plusieurs extlangs la suivaient. Ainsi, l'arabe tunisien était ar-aeb et le zapotèque de la Sierra de Juárez était zap-zaa (zap étant la sous-étiquette de la macrolangue zapotèque).

Pour comprendre l'intérêt de ce système, il faut voir que les logiciels qui manipulent les étiquettes de langue, lorsqu'ils ne trouvent pas une langue satisfaisante, cherchent en général en supprimant les sous-étiquettes en partant de la droite, où se trouvent les sous-étiquettes les moins significatives (ce mécanisme est décrit dans le RFC 4647). Ainsi, si on demande à un système de recherche un document en az-Arab-IR (l'azéri écrit dans l'écriture arabe tel qu'il est utilisé en Iran), et qu'aucun document ne correspond à cette étiquette, le logiciel peut chercher s'il a az-Arab (en abandonnant les spécificités iraniennes) ou même az (de l'azéri, quelles que soient ses autres caractéristiques). Les extlangs collaient bien à ce modèle. Une demande de sq-als (le tosque) serait ainsi tronquée en sq (la macrolangue pour l'albanais), ce qui ne serait pas une mauvaise solution de repli.

Mais, à l'examen plus attentif des extlangs, plusieurs problèmes sont survenus. D'abord, la constation que le repli en tronquant par la droite ne donnait pas toujours des résultats corrects. Rien ne garantit que les langues couvertes par une même macrolangue sont mutuellement compréhensibles, bien au contraire. Donc, le repli « aveugle » obtenu en supprimant les sous-étiquettes en partant de la droite ne va pas être satisfaisant. Ensuite, les extlangs compliquent le modèle puisqu'ils représentent un nouveau cas à spécifier, à implémenter et à expliquer. Enfin, les extlangs peuvent porter un message erroné, celui comme quoi une langue particulière du groupe serait la langue principale. Ce message peut être souhaité (la plupart des arabophones sont très attachés à la référence à une langue arabe unique), ou pas mais il est toujours délicat, puisqu'il place les langues dans une hiérarchie. De nombreuses discussions, parfois houleuses, avaient animé le groupe de travail autour de ces problèmes.

C'est ainsi que LTRU avait, en décembre 2007, renoncé à utiliser les extlangs et changé les Internet-Drafts pour mettre en œuvre cette décision. Dans cette nouvelle version, le registre des langues gardait l'information comme quoi une langue était couverte par une macrolangue mais les étiquettes de langue étaient uniquement formées avec la langue elle-même. Le tosque était donc noté als, le zapotèque de la Sierra de Juárez zaa et le mandarin cmn.

Mais, à l'IETF, les choses ne se passent pas toujours aussi simplement. Cinq mois après ce changement, les problèmes de la nouvelle version apparaissent, souvent soulevés par des gens qui n'avaient guère contribué au travail concret, et rien dit à l'époque de l'abandon des extlangs. Dans les cas où le groupe autour d'une macrolangue comporte une langue dominante (ce qui est le cas du chinois avec le poids du mandarin, ou celui de l'arabe avec la référence qu'est l'arabe standard, mais pas du zapotèque), de nombreux documents ont déjà été étiquetés avec l'étiquette qui est devenue celle de la macrolangue. Par exemple, les ressources en mandarin ne devraient plus être notées zh comme avant mais cmn. Que faire avec les innombrables documents en mandarin qui avaient été étiquetés zh en suivant le RFC 4646 ?

Idéalement, le seul registre des langues suffirait à trouver des bonnes solutions. Mais, en fait, les décisions à prendre par le logiciel dépendent souvent de critères non linguistiques. Par exemple, si un utilisateur a configuré comme langue préférée le breton, il n'est pas déraisonnable de lui servir du texte en français. Non pas que les deux langues soient proches (la première est une langue celte et le second une langue romane) mais parce que, en pratique, presque tous les gens qui comprennent le breton comprennent également le français. Mais on ne peut pas mettre cette information (de taille importante et qui change souvent) dans le registre ! Il faudrait donc se résigner, ce qui ne semble pas facile, à ne pas avoir dans le registre d'information permettant un repli « intelligent ».

Après, là encore, un débat très chaud, le groupe LTRU a finalement fait marche arrière le 26 mai 2008, revenant aux extlangs. Cela nécessite de revenir à la précédente version des Internet-Drafts, de revoir documents et implémentations. Et sans garantie que cela ne recommence pas dans quelques mois...

Ma vue personnelle est que le système est instable : on peut bâtir un bon argumentaire pour les deux solutions (contre les extlangs, voir le texte de Mark Davis), aucune n'est parfaite, car les langues humaines n'ont pas été conçues pour faciliter la tâche de l'IETF. Il aurait fallu adopter une solution et s'y tenir mais les mécanismes de décision à l'IETF ne rendent pas cela facile.

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)