Кратко

  • В публикации от 5 октября добавлены справочные правила для яванской и канадской слоговой письменности коренных народов, а также обновлены ещё семь наборов. Межписьменные варианты превращают релиз в связанный пакет изменений, а не в два отдельных дополнения.
  • Правила второго уровня помогают реестрам разрабатывать и проверять IDN-таблицы. Число охваченных письменностей не доказывает делегирование доменов верхнего уровня, совместимость всех приложений или фактическое распространение.

Анализ

Перечень языков легко принять за каталог. Публикацию ICANN от 5 октября точнее рассматривать как карту зависимостей.

ICANN выпустила справочные правила генерации меток (LGR) второго уровня для яванской письменности и канадской слоговой письменности коренных народов (UCAS), а также обновила семь других наборов: арабскую письменность, арабский язык, язык инуктитут, японский язык, японскую письменность, латинскую письменность и полный набор латинских вариантов. По данным ICANN, опубликованные справочные LGR теперь охватывают 30 письменностей и 32 языка. Это число описывает доступные справочные материалы, а не количество языков, которые полностью работают в каждом регистраторе, браузере, почтовой системе и приложении.

Примечания к обновлению показывают, почему одного подсчёта дополнений недостаточно. Новое правило UCAS сопровождается дополнительными межписьменными вариантами в правилах языка инуктитут. Добавление латинского символа для поддержки алгонкинских языков в Канаде также повлекло изменения межписьменных вариантов в полном наборе латинских вариантов. Правила для японского языка и письменности приведены в соответствие с шестой версией LGR корневой зоны. Изменения арабской письменности поддерживают индонезийское письмо пегон. Каждый пункт связан с другими правилами, которые реестрам и проверяющим группам может потребоваться учитывать.

Это важно, потому что правила участвуют в практических решениях. ICANN описывает справочные LGR второго уровня как материал для операторов реестров общих доменов верхнего уровня, разрабатывающих таблицы интернационализированных доменных имён (IDN). ICANN также использует их при проверке поданных реестрами таблиц на безопасность и стабильность. Таблица определяет, какие метки конкретная зона принимает по своей политике и как обращается с вариантами. Поэтому изменение справочного файла может затронуть анализ реестра и за пределами письменности, указанной в заголовке объявления.

Это не означает, что реестры уже приняли октябрьские версии или что все связанные таблицы должны измениться одинаково. Сначала нужно разобраться с версиями: какой набор использовал оператор, что поменялось и какие поддерживаемые метки либо отношения вариантов следует протестировать заново? Если отслеживать только две новые письменности, можно пропустить связанное обновление в собственной IDN-таблице или процедуре её проверки.

Важно также не смешивать уровни. Справочные LGR второго уровня относятся к IDN-таблицам, применяемым под общими доменами верхнего уровня. Руководство заявителя для раунда 2026 года использует шестую версию LGR корневой зоны, чтобы проверять строки верхнего уровня и вычислять их варианты. Системы связаны техническим согласованием и зависимостями, но отвечают на разные вопросы. Справочное правило второго уровня само по себе не утверждает новую доменную зону верхнего уровня, не делегирует метку и не даёт заявителю права на её использование.

В итогах общественного обсуждения ICANN указано 33 содержательных комментария: 32 поддержали предложенные новые и обновлённые правила, один касался опечатки и уточнения в яванском наборе. Это свидетельство того, какие отзывы получила ICANN, а не голосование всех реестров, пользователей письменностей или языковых сообществ. Формулировку о разработке правил совместно с сообществами тоже нужно понимать в этих границах: участвовали профильные специалисты и группы, но у числа комментариев есть конкретная аудитория и цель.

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

Практический ответ для реестров — вести выпуск как набор изменений. Сравнить новую версию с применяемой, связать каждое изменение со своей IDN-таблицей, протестировать затронутые метки и варианты, согласовать даты политики и внедрения с поставщиками услуг реестра. Межписьменным связям нужен отдельный разбор: пользователи и реестры работают с целыми метками, а не с разрозненными списками кодовых точек.

Главный вопрос не только в том, сколько письменностей добавила ICANN. Нужно понять, сохранит ли набор правил внутреннюю согласованность по мере расширения охвата. Октябрьская публикация показывает, как одно дополнение распространяется по связям: новая письменность может потребовать пересмотра вариантов другого языка, а новый символ — изменить полный межписьменный набор. Каталог одновременно становится поверхностью для обслуживания.