Resumen

  • RFC 3066 normalizó una gramática de etiquetas sin distinción de mayúsculas, un registro público y un rango lingüístico basado en prefijos, pero dejó que cada aplicación definiera qué afirmaba la etiqueta sobre su objeto.
  • El documento advirtió expresamente que compartir prefijo no garantizaba inteligibilidad mutua. Una coincidencia era un resultado de selección, no prueba de etiquetado correcto, buen renderizado o comprensión.

Una etiqueta pequeña para un hecho humano enorme

Internet no necesitaba una teoría universal del lenguaje para transportar información multilingüe. Necesitaba un identificador común que correo, HTTP, marcado, bibliotecas y síntesis de voz pudieran usar sin inventar vocabularios privados.

RFC 3066, publicada como BCP 47 y sustituta de RFC 1766, ofreció ese mínimo. Una etiqueta tenía un subtag primario y cero o más subtags separados por guion. Las mayúsculas no cambiaban el significado. Los códigos primarios de dos letras procedían de ISO 639; los de tres, de ISO 639-2. i reservaba una rama registrada por IANA y x una rama privada. Un segundo subtag de dos letras podía señalar un área ISO 3166.

La gramática coordinaba la escritura, no nombraba a un dueño único de la verdad lingüística. Los organismos ISO asignaban códigos. IANA administraba el espacio y los registros públicos. El protocolo definía la relación entre etiqueta y objeto. El emisor elegía la etiqueta; la aplicación decidía cómo actuar; el lector experimentaba el resultado.

El contexto era dueño de la afirmación

RFC 3066 no dio un significado único a “este objeto tiene idioma X”. En un documento, varios tags podían indicar los idiomas necesarios para comprenderlo por completo. En una colección, podían enumerar idiomas presentes en sus partes. En un conjunto de alternativas, solo orientaban hacia cada variante. En HTML o XML, una etiqueta podía aplicarse a un fragmento y ayudar a un diccionario o sintetizador de voz.

Los caracteres eran iguales; la afirmación no. Un campo llamado language puede describir el texto, la preferencia del usuario, la interfaz, las alternativas o la salida solicitada. Aunque todos contengan es, no son el mismo dato.

El RFC también pidió precisión solo cuando fuera conocida y útil. Si existía un código ISO 639-1 de dos letras, debía preferirse al de tres. Si el protocolo no obligaba a declarar algo, omitir era mejor que usar und para lo desconocido. Si admitía varias etiquetas, varias etiquetas eran mejores que mul. Lo desconocido y lo múltiple debían conservarse como estados reales.

El prefijo era un filtro, no un árbol genealógico

La incorporación clave frente a RFC 1766 fue language-range. Un rango coincidía con una etiqueta idéntica o con un prefijo terminado justo antes de un guion. * podía coincidir con cualquier etiqueta bajo reglas adicionales del protocolo. Una petición amplia podía reunir variantes más específicas.

El texto limitó inmediatamente la inferencia: que dos etiquetas comiencen igual no garantiza que sus idiomas sean mutuamente inteligibles. La jerarquía de cadenas no demuestra una jerarquía de comprensión humana.

RFC 4647 llamó después a ese algoritmo Filtrado Básico y lo separó del Filtrado Extendido y la Búsqueda. Un filtro devuelve un conjunto; una búsqueda elige una etiqueta. Ninguna operación pregunta al lector. La coincidencia solo dice que cadenas declaradas cumplieron un algoritmo y una prioridad. No demuestra dominio, dialecto, escritura, accesibilidad, calidad de traducción ni que el contenido estuviera bien etiquetado.

Por eso una cadena de evidencia conserva por separado la preferencia enviada, las etiquetas disponibles, el algoritmo, el objeto elegido, su idioma real, el renderizado, la corrección del usuario y el resultado de la tarea. Reducirlo a language_match=true concede a una comparación textual una autoridad que nunca tuvo.

El registro guardaba memoria, no comprensión

Los tags fuera de las reglas generativas requerían revisión pública. El solicitante aportaba descripción y referencia; una lista abierta debatía durante dos semanas; un revisor enviaba o rechazaba la petición. Los registros no se borraban. Si un tag quedaba obsoleto, se marcaba como desaprobado y se indicaba su sustituto.

Eso preservaba memoria institucional. Permitía interpretar datos antiguos y saber qué debía significar una etiqueta. No certificaba cada documento que la usaba. El registro respondía “¿qué identificador compartimos?”, no “¿está realmente este texto en ese idioma?”.

La rama x- exponía aún mejor el límite. Partes privadas podían acordar un significado, pero IANA no registraba el resto del tag y el Internet público no tenía obligación de entenderlo.

RFC 4646 reemplazó en 2006 el registro de etiquetas enteras por un Registro de Subtags estructurado, con posiciones explícitas para idioma, escritura, región y variante y reglas de estabilidad más fuertes. RFC 5646 refinó la arquitectura y forma hoy BCP 47 junto con RFC 4647. IANA conserva cerrado y obsoleto el registro de RFC 3066.

Una estructura mejor ayuda a analizar y conservar etiquetas; no las convierte en observaciones sobre comprensión.

La preferencia también exponía a la persona

RFC 3066 añadió un riesgo concreto que RFC 1766 no había reconocido: un rango enviado durante negociación podía ayudar al receptor a inferir nacionalidad y elegir objetivos de vigilancia. No afirmaba que idioma y nacionalidad fueran equivalentes; advertía de que un observador podía tratarlos así.

Una preferencia revelada para mejorar el servicio se convertía en señal reutilizable. El selector necesitaba información suficiente para escoger una representación; los registros, la correlación y la retención podían darle otro propósito. La práctica responsable limita la divulgación, no infiere identidad y separa el comprobante de selección de perfiles construidos para otros fines.

Fuentes