Résumé
- La RFC 3066 a normalisé une grammaire d’étiquettes insensible à la casse, un enregistrement public et une plage de langues fondée sur les préfixes, tout en laissant à chaque application le soin de définir le rapport entre l’étiquette et l’objet.
- Le texte avertissait expressément qu’un préfixe commun ne garantissait pas l’intercompréhension. Une correspondance était un résultat de sélection, non une preuve de bon étiquetage, de rendu correct ou de compréhension.
Une petite étiquette pour un fait humain immense
L’Internet n’avait pas besoin d’une théorie universelle du langage pour acheminer des contenus multilingues. Il lui fallait un identifiant commun que le courrier, HTTP, les langages de balisage, les bibliothèques et la synthèse vocale puissent transporter sans vocabulaire privé propre à chaque système.
Publiée comme BCP 47 et remplaçant la RFC 1766, la RFC 3066 a fourni ce minimum. Une étiquette comprenait un sous-tag principal puis, éventuellement, d’autres sous-tags séparés par des traits d’union. La casse ne portait aucun sens. Les codes primaires à deux lettres provenaient d’ISO 639, ceux à trois lettres d’ISO 639-2. i ouvrait la branche enregistrée par l’IANA, x l’usage privé. Un deuxième sous-tag de deux lettres pouvait désigner une zone ISO 3166.
Cette grammaire rendait l’orthographe interopérable. Elle ne créait pas de propriétaire unique de la vérité linguistique. Les organismes ISO attribuaient les codes sources. L’IANA administrait l’espace de noms. Le protocole porteur définissait le lien avec l’objet. L’émetteur choisissait l’étiquette, l’application réceptrice décidait d’en faire quelque chose, et le lecteur vivait le résultat.
Le contexte possédait le sens de l’assertion
La RFC refusait d’imposer un sens unique à « cet objet porte la langue X ». Pour un document, plusieurs tags pouvaient nommer les langues nécessaires à sa compréhension complète. Pour une collection, ils pouvaient seulement inventorier les langues présentes. Pour un ensemble d’alternatives, ils servaient d’indices conduisant à examiner chaque version. Dans HTML ou XML, une étiquette pouvait viser un seul passage et aider un dictionnaire ou une voix de synthèse.
Les caractères restaient identiques ; l’assertion changeait. Un champ language peut décrire le texte, une préférence du lecteur, l’interface, les variantes disponibles ou la sortie demandée. Même si chacun vaut fr, ces affirmations ne sont pas interchangeables.
Le document recommandait aussi de n’être précis que lorsque la précision était connue et utile. Le code ISO 639-1 à deux lettres devait l’emporter lorsqu’il existait. Si le protocole n’exigeait aucune valeur, l’absence était préférable à und pour une langue inconnue. S’il acceptait plusieurs tags, ceux-ci étaient préférables au raccourci mul. L’inconnu et le multiple devaient rester visibles.
Le préfixe était un filtre, pas un arbre de parenté
L’apport marquant par rapport à la RFC 1766 fut la language-range. Une plage correspondait à un tag identique ou à son préfixe terminé sur une frontière de trait d’union. * pouvait correspondre à tout, sous réserve du sens défini par le protocole. Une demande large pouvait ainsi réunir des variantes plus précises.
La RFC bornait aussitôt cette facilité : deux langues dont les tags commencent pareil ne sont pas nécessairement mutuellement intelligibles. La hiérarchie des chaînes ne prouve aucune hiérarchie de compréhension humaine.
La RFC 4647 a ensuite baptisé cet algorithme « filtrage de base » et l’a distingué du filtrage étendu et de la recherche d’une meilleure valeur. Le filtre renvoie un ensemble ; la recherche choisit une étiquette. Aucun des deux n’interroge le lecteur. Le succès signifie seulement que des chaînes déclarées ont satisfait un algorithme et une liste de priorités. Il ne dit rien, à lui seul, sur la maîtrise de la langue, le dialecte, l’écriture, l’accessibilité, la qualité d’une traduction ou une erreur d’étiquetage.
Une chaîne de preuves honnête garde donc séparés la préférence transmise, les étiquettes candidates, l’algorithme, l’objet choisi, sa langue réelle, son rendu, la correction éventuelle par l’utilisateur et l’issue de la tâche. Réduire tout cela à language_match=true donne à une comparaison de texte une autorité qu’elle n’a jamais reçue.
Le registre conservait une mémoire, pas la compréhension
Les tags extérieurs aux règles génératives passaient par un examen public. Le demandeur fournissait une description et une référence ; la liste ouverte discutait pendant deux semaines ; un réviseur transmettait ou rejetait la demande. Les inscriptions n’étaient pas supprimées. Une valeur dépassée était marquée comme déconseillée avec son remplacement.
Ce mécanisme protégeait la mémoire institutionnelle. Il permettait d’interpréter d’anciennes données et d’identifier ce qu’un tag était censé désigner. Il ne certifiait pas chaque document portant ce tag. L’enregistrement répondait à « quel identifiant partageons-nous ? », non à « ce texte est-il réellement dans cette langue ? ».
Le cas x- rendait la limite explicite. Une communauté privée pouvait convenir d’une signification, mais l’IANA n’enregistrait pas la suite du tag et le reste de l’Internet ne lui devait aucune interprétation.
En 2006, la RFC 4646 a remplacé l’enregistrement de tags entiers par un registre structuré de sous-tags. Elle a rendu explicites la langue, l’écriture, la région et les variantes, puis renforcé la stabilité. La RFC 5646 a affiné cette architecture et forme aujourd’hui la BCP 47 avec la RFC 4647. L’IANA conserve désormais l’ancien registre RFC 3066 fermé et obsolète.
Une meilleure structure facilite l’analyse et la conservation. Elle ne transforme toujours pas l’étiquette en observation de la compréhension.
Une préférence révélait aussi une personne
La RFC 3066 a ajouté un risque concret que la RFC 1766 n’avait pas retenu : une plage de langues envoyée lors d’une négociation pouvait servir à inférer une nationalité et à sélectionner des cibles de surveillance. Le texte ne disait pas que langue et nationalité étaient identiques ; il constatait que le destinataire pouvait faire ce raccourci.
Une préférence fournie pour améliorer le service devenait ainsi un signal réutilisable. Le moteur de sélection n’avait besoin que d’assez d’information pour choisir une représentation ; les journaux, la corrélation et la rétention pouvaient donner à ce signal une seconde vie. La discipline consiste à limiter la divulgation, à ne pas en déduire une identité et à séparer la preuve nécessaire au choix d’un profil construit à d’autres fins.
Sources
- https://www.rfc-editor.org/rfc/rfc3066.html
- https://www.rfc-editor.org/info/rfc3066/
- https://datatracker.ietf.org/doc/rfc3066/
- https://www.rfc-editor.org/rfc/rfc1766.html
- https://www.rfc-editor.org/rfc/rfc2277.html
- https://www.rfc-editor.org/rfc/rfc4646.html
- https://www.rfc-editor.org/rfc/rfc4647.html
- https://www.rfc-editor.org/rfc/rfc5646.html
- https://www.iana.org/assignments/language-subtags-tags-extensions
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
