Кратко

  • RFC 1766 показывал структуру языковой метки, но требовал обрабатывать её целиком как один токен; подметки служили администрированию, а не меню.
  • Коды ISO, регистрации IANA и частное пространство занимали разные позиции в синтаксисе. Связь метки с информационным объектом должна была определяться спецификацией контекста.
  • Позднейшие редакции добавили явно заданные операции сопоставления. Они не превратили каждый дефис в грамматике 1995 года в универсальный путь навигации.

Дефис напоминал хлебные крошки

В марте 1995 года RFC 1766 предложил компактный способ помечать язык информационного объекта. Форма могла напоминать дерево: основная метка, за которой следуют необязательные части, разделённые дефисами. en-US выглядело знакомо; az-arabic и az-cyrillic начинались одинаково. Однако документ чётко ограничил такую трактовку: приложения должны считать всю языковую метку единым токеном. Деление на основную часть и подметки было административным механизмом, а не средством навигации.

Это важно, потому что читаемая строка не становится иерархией команд. Основная метка могла содержать от одной до восьми букв; тот же предел действовал для каждой подметки. Пробелы внутри строки не допускались. Регистр не менял значение. Существовали соглашения писать коды стран заглавными, а языковые коды строчными буквами, но RFC 1766 пояснял, что сама капитализация не несёт смысла.

У пространства имён были чёткие границы. Двухбуквенные основные метки следовали ISO 639. Значение i резервировалось для регистраций, определяемых IANA; x открывало область частного использования, подметки которой IANA регистрировать не должна. Прочие основные значения требовали пересмотра стандарта. В первой подметке двухбуквенные коды следовали ISO 3166 alpha-2, а значения длиной от трёх до восьми букв можно было зарегистрировать в IANA. Регистрировались и последующие подметки.

У этой структуры было две функции, которые легко спутать: строку можно было читать по частям, а пространство имён — администрировать по установленным правилам. Документ не предписывал проходить эти части как каталоги. Он также не приписывал каждому сегменту единый смысл во всех приложениях. Связь метки с информационным объектом определяла спецификация контекста, в котором метка появлялась.

Регистрация делала значения публично проверяемыми

Примеры RFC 1766 охватывали обозначение страны (en-US), диалекта или варианта (no-nynorsk, en-cockney), язык, зарегистрированный IANA (i-cherokee), и варианты письменности (az-arabic, az-cyrillic). В документе было существенное уточнение: ни одна из показанных подметок ещё не была назначена. Примеры иллюстрировали синтаксис, а не перечень доступных значений.

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

Область действия процедуры тоже была ограничена: она регистрировала идентификаторы и справочные материалы, а не универсальный интерфейс. Сама метка не говорила каждому протоколу, какую форму выбрать, какую библиотеку отфильтровать, какой маршрут открыть или какое языковое меню показать. Такое поведение определялось контекстом использования.

Заголовок мог перечислить языки, но не задавал механизм выбора

RFC 1766 также определил Content-Language, в котором можно было перечислить несколько полных меток. Для MIME multipart/alternative появился параметр Differences, указывающий, что альтернативные части различаются языком содержимого. Документ объяснял, почему программа чтения может использовать эти сведения, но оставлял за пределами своего охвата механизм выбора отображаемой части.

Так оставались разделены три вопроса: какая строка обозначает язык объекта, какой элемент протокола её переносит и что делает с ней принимающее приложение. Метка могла находиться в заголовке содержимого; контейнер мог сообщать о языковых вариантах; программе чтения всё равно требовалась собственная логика выбора. RFC предоставил общую метку и место для её передачи, но не универсальную навигацию.

Позднейшие документы сделали это разграничение конкретнее. RFC 3066 2001 года разрешил цифры в подметках и ввёл понятие language-range. Диапазон мог совпасть с полной меткой или с префиксом, заканчивающимся на границе дефиса. Это была чётко заданная операция сопоставления. Затем RFC 3282 описал заголовки Content-Language и Accept-Language, включая предпочтительные языковые диапазоны и необязательные значения качества. Эти дополнения установили явные протокольные действия вокруг меток, но не превратили исходный дефис в общий маршрут.

RFC 4646 2006 года и RFC 5646 2009 года продолжили пересмотр BCP 47. Эта последовательность показывает, что грамматика и реестр менялись. Она не доказывает, что каждый клиент правильно обрабатывал любое значение или что метка автоматически выбирала страницу, перевод либо способ отображения. Исторический вывод из RFC 1766 уже: структурированный идентификатор может оставаться для приложения неделимым значением, тогда как его части служат административным соглашениям.

Источники и пределы

Основная спецификация — RFC 1766. Последующие редакции описаны в RFC 3066, RFC 3282, RFC 4646 и RFC 5646. Эти документы подтверждают синтаксис, регистрацию и дальнейшие изменения протоколов, но не повсеместное внедрение.