Кратко

  • RFC 3066 унифицировал синтаксис языковых тегов, их публичную регистрацию и сопоставление языковых диапазонов, но оставил каждому протоколу право определять, что именно тег утверждает об информационном объекте.
  • Документ прямо предупредил: общая последовательность тегов-префиксов не гарантирует взаимопонимания. Совпадение — результат выбора по правилу, а не свидетельство верной метки, качественного отображения или понимания читателя.

Короткая метка для большого человеческого факта

Чтобы обмениваться многоязычной информацией, Интернету не требовалась единая теория языка. Нужен был общий идентификатор, который могли передавать почта, веб, разметка, документные коллекции и речевые инструменты — без отдельного словаря в каждом приложении.

RFC 3066 вышел в январе 2001 года как BCP 47 и заменил RFC 1766. Тег состоял из основной части и, возможно, нескольких субтегов, разделённых дефисами. Регистр букв не менял значения. Двухбуквенные основные значения брались из ISO 639, трёхбуквенные — из ISO 639-2; i открывал ветвь регистрации IANA, а x предназначался для частного использования. Так задавались форма и источник кода, но не способность читателя понять текст.

Полномочия оставались распределёнными. Органы ISO поддерживали исходные кодовые наборы, IANA вела пространство имён и публичные регистрации, отправитель выбирал тег, протокол определял его связь с содержимым, а приложение решало, как его использовать. Общий префикс не делал обозначенные им языки взаимопонятными.

Смысл утверждения задавал контекст

RFC 3066 не закреплял единственного смысла за фразой «этот объект помечен тегом X». Для одного документа набор тегов мог обозначать языки, необходимые для полного понимания. В коллекции он мог перечислять языки её частей. В наборе альтернативных представлений теги служили подсказкой, что нужно проверить каждую версию. В HTML или XML метку можно было привязать к отдельному фрагменту, чтобы словарь или синтезатор речи применил подходящие правила.

Строка одна, утверждения разные. Поле language может обозначать язык текста, предпочтение пользователя, язык интерфейса или набор доступных вариантов. Стандарт, использующий поле, обязан указать, что именно оно значит.

Отправителю следовало указывать самый точный тег, который ему известен и полезен в данном контексте. Если существовал соответствующий двухбуквенный код ISO 639-1, он имел преимущество перед трёхбуквенным. Когда протокол не требовал значения, при неизвестном языке обычно было лучше опустить тег, чем ставить und. Если протокол допускал несколько тегов, не следовало сворачивать их в mul. Неизвестное и многоязычное — это состояния, а не дефекты оформления.

Префикс — фильтр, а не генеалогическое древо

RFC 3066 ввёл понятие language-range для набора тегов, начинающихся с одной последовательности субтегов. Диапазон совпадал с тегом либо точно, либо как префикс, заканчивающийся на границе дефиса. * мог соответствовать любому тегу, если протокол не задавал для него дополнительных правил. Так приложение получало простой способ найти более конкретно размеченные варианты содержимого.

Но RFC сразу ограничил вывод: общая последовательность префикса не гарантирует взаимопонимания языков. Позднее RFC 4647 назвал базовую схему Basic Filtering и отделил её от расширенной фильтрации и поиска подходящего варианта. Фильтр возвращает набор, механизм поиска выбирает тег — ни тот, ни другой не спрашивает читателя, способен ли он прочесть результат.

Поэтому нужны разные свидетельства: раскрытое предпочтение, доступные метки, алгоритм и порядок выбора, выбранный объект, фактический язык, качество отображения или речи, исправление пользователя и итог задачи. Сведение всего к language_match=true наделяет сравнение строк человеческим смыслом, которого RFC не обещал.

Регистрация создавала память, но не понимание

Теги за пределами общих правил проходили публичное рассмотрение в списке языков IETF. После двух недель назначенный эксперт мог передать запрос в IANA или отклонить его при существенных публичных возражениях. Регистрации не удалялись: устаревшую запись меняли, указывая рекомендуемый код на замену. Так сохранялась история идентификатора и возможность понять старые данные. Но это не доказывало, что любой документ с таким тегом действительно был написан на соответствующем языке.

Ветка x- показывала ещё одну границу: стороны могли договориться о частной метке, однако ни IANA, ни глобальный стандарт не придавали ей универсального значения. Частная координация оставалась допустимой, пока её не выдавали за общую совместимость.

Позднее RFC 4646 заменил каталог целых тегов более структурированным реестром субтегов; RFC 5646 развил эту архитектуру и вместе с RFC 4647 образует нынешний BCP 47. Разбор тегов стал предсказуемее, а их идентичность — устойчивее. Но новая структура не превратила метку в наблюдение за человеческим пониманием.

Раскрытие предпочтения имеет цену

RFC 3066 отметил, что языковые диапазоны в согласовании содержимого могут использоваться для предположения о гражданстве отправителя и поиска целей для наблюдения. Документ не приравнивал язык к гражданству: риск состоял в выводах, которые наблюдатель мог сделать по раскрытому предпочтению.

Пользователь сообщил о предпочтении, чтобы получить подходящий вариант, но получатель также получил сигнал, который можно записать и связать с другими данными. Необходимость однажды выбрать представление не означает, что сигнал следует хранить постоянно или объединять с профилем личности. Оценку угроз и меры защиты RFC оставил каждому прикладному протоколу.

Источники