Процесс стандартизации

Международный API в JavaScript формализован как часть спецификации ECMA-402, которая развивается параллельно с базовой спецификацией языка ECMA-262. Такое разделение обусловлено тем, что интернационализация затрагивает не только синтаксис языка, но и взаимодействие с внешними стандартами локализации, которые определяются международными организациями и библиотеками данных.

ECMA-402 описывает поведение объектов Intl и их компонентов, а именно форматирование дат, чисел, списков, сравнений строк и локализованных представлений. При этом сама спецификация не реализует алгоритмы локализации напрямую, а опирается на внешние источники данных и индустриальные стандарты.

Ключевая особенность стандартизации Intl API заключается в том, что она находится на пересечении нескольких доменов:

  • стандарт языка программирования (ECMAScript),
  • стандарты Unicode Consortium,
  • данные локализации CLDR (Common Locale Data Repository),
  • реализация ICU (International Components for Unicode).

Такое взаимодействие формирует многоуровневую систему, где спецификация определяет поведение, но не хранит локализационные данные.

Организация TC39 и жизненный цикл спецификации

Развитие ECMAScript, включая ECMA-402, управляется комитетом TC39 (Technical Committee 39). Этот комитет отвечает за эволюцию JavaScript как языка и рассматривает предложения по изменению стандарта.

Любое изменение проходит формализованный процесс, включающий несколько стадий зрелости предложения:

Stage 0 — идея (Strawman)

На этом этапе предложение существует как концепция. Оно может быть представлено участником комитета или внешним разработчиком. Формальной спецификации нет.

Stage 1 — Proposal

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

Stage 2 — Draft

Формализуется спецификация поведения. На этом этапе описываются алгоритмы и семантика API. Для Intl это может включать новые методы форматирования или расширение локалей.

Stage 3 — Candidate

Предложение считается почти готовым к стандартизации. Реализации появляются в движках JavaScript, а обратная связь от разработчиков активно учитывается.

Stage 4 — Finished

Стандарт утверждён. Включается в финальную спецификацию ECMAScript и становится частью официального поведения языка.

Intl API исторически развивался через этот процесс, включая такие расширения, как Intl.DateTimeFormat, Intl.NumberFormat, Intl.Collator, Intl.RelativeTimeFormat.

Связь ECMA-402 и ECMA-262

ECMA-262 определяет базовую семантику Jav * aScript: типы данных, выражения, объекты, функции. ECMA-402 расширяет язык набором встроенных объектов, которые предоставляют международные функции.

Связь между ними выражается в следующих аспектах:

  • ECMA-262 определяет механизм добавления встроенных объектов.
  • ECMA-402 использует этот механизм для внедрения Intl.
  • поведение Intl описывается отдельной спецификацией, но интегрируется в общий runtime.

Таким образом, Intl API не является внешней библиотекой, а частью языка, хотя и логически выделенной в отдельный стандарт.

Роль Unicode Consortium

Unicode Consortium играет центральную роль в стандартизации интернационализации. Основные зависимости Intl API:

  • Unicode Locale Identifier (BCP 47 расширения),
  • Unicode CLDR (данные локализации),
  • Unicode Collation Algorithm (UCA),
  • Common Locale Data Repository.

CLDR содержит огромные массивы данных:

  • форматы дат и времени,
  • правила множественного числа,
  • числовые системы,
  • названия месяцев и дней недели,
  • правила сортировки.

ECMA-402 не дублирует эти данные, а ссылается на них. Это позволяет поддерживать актуальность локализаций без изменения спецификации языка.

IETF BCP 47 и идентификация локалей

Одним из ключевых элементов стандартизации является формат идентификаторов локалей, основанный на BCP 47 (Best Current Practice).

Структура локали:

  • язык (en, ru, zh),
  • регион (US, RU, CN),
  • дополнительные расширения (u-extensions),
  • скрипт (Latn, Cyrl, Hans).

Пример:

ru-RU
en-US
zh-Hans-CN

Intl API использует эти идентификаторы как входной параметр для определения правил форматирования. Спецификация описывает механизм разрешения локали (locale resolution), включая fallback-цепочки.

Алгоритмы спецификации и формализация поведения

ECMA-402 описывает поведение Intl через формальные алгоритмы, которые имеют строгую псевдокодовую структуру.

Например, создание форматтера чисел:

  • проверка переданной локали,
  • нормализация параметров,
  • выбор наиболее подходящей локали,
  • загрузка соответствующих данных CLDR,
  • создание внутреннего formatter object.

Алгоритмы стандарта не зависят от конкретной реализации движка. Это обеспечивает совместимость между различными средами: V8, SpiderMonkey, JavaScriptCore.

ICU как базовая реализация

Практическая реализация Intl API в большинстве JavaScript-движков основана на библиотеке ICU (International Components for Unicode).

ICU предоставляет:

  • форматирование дат и времени,
  • обработку локалей,
  • алгоритмы сортировки,
  • числовое форматирование,
  • поддержку Unicode.

Связь ICU и ECMA-402 заключается в том, что спецификация часто формулируется в терминах ICU-подобных операций. Однако формально стандарт не требует использования ICU, позволяя альтернативные реализации.

Версионирование стандарта и эволюция API

ECMA-402 развивается быстрее, чем базовый ECMAScript в ранние годы. Это связано с высокой потребностью в локализации современных приложений.

Основные этапы эволюции:

  • ранние версии включали базовое форматирование чисел и дат,
  • последующие добавили колlation (Intl.Collator),
  • затем появились относительные времена (Intl.RelativeTimeFormat),
  • позже — расширенные функции списков и множественных форм.

Каждое расширение проходит через TC39 и синхронизируется с реализациями движков.

Политика обратной совместимости

Одним из фундаментальных принципов стандартизации Intl является строгая обратная совместимость.

Изменения в спецификации не должны:

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

Если требуется изменение поведения, оно вводится как:

  • новый параметр,
  • новый метод,
  • новая версия алгоритма с fallback.

Это делает Intl API стабильным компонентом языка, пригодным для долгосрочного использования в продуктивных системах.

Фичефлаги и стадия внедрения в движках

Реализация Intl в браузерах и Node.js проходит отдельный жизненный цикл внедрения:

  • экспериментальная поддержка,
  • частичная реализация,
  • полная реализация стандарта.

Для проверки доступности используются механизмы feature detection:

  • наличие конструктора Intl.NumberFormat,
  • поддержка конкретных локалей,
  • поведение resolvedOptions().

Такой подход позволяет синхронизировать развитие стандарта и внедрение в runtime без нарушения стабильности экосистемы.

Политика локалей и fallback-механизм

Спецификация определяет строгую модель выбора локали:

  1. принимается предпочтительная локаль,
  2. проверяется доступность в окружении,
  3. выполняется fallback на ближайшую совместимую,
  4. при отсутствии — используется дефолтная локаль среды.

Этот механизм стандартизирует поведение между различными платформами и предотвращает расхождения между браузерами и серверными реализациями.

Роль флага Unicode extensions (u-extensions)

BCP 47 позволяет расширять локали через -u- параметры, которые влияют на поведение форматтеров.

Примеры:

  • выбор календаря,
  • тип числовой системы,
  • режим сортировки.

Стандарт описывает, как эти расширения интерпретируются и как они влияют на выбор алгоритмов внутри Intl API. Это обеспечивает гибкость без расширения самого языка JavaScript.

Совместимость реализаций и тестирование стандарта

Для поддержания консистентности между реализациями используются тестовые наборы:

  • Test262 — основной тестовый набор ECMAScript,
  • дополнительные тесты ECMA-402.

Тестирование включает:

  • проверку идентичности результатов форматирования,
  • корректность fallback-локалей,
  • соответствие Unicode-алгоритмам,
  • стабильность API.

Разработчики движков используют эти тесты как эталон соответствия стандарту.

Влияние спецификации на архитектуру движков

Intl API оказывает значительное влияние на архитектуру JavaScript-движков:

  • необходимость интеграции ICU как внешней зависимости,
  • поддержка больших локализационных данных,
  • кеширование formatter-объектов,
  • оптимизация создания Intl-инстансов.

Форматтеры считаются тяжёлыми объектами, поэтому движки оптимизируют их через внутренние кеши и lazy initialization.

Интеграция с веб-экосистемой

Intl API стандартизируется не только внутри ECMAScript, но и в контексте веб-платформы. Он используется совместно с:

  • API форматирования времени в браузерах,
  • локализацией интерфейсов,
  • серверными рендеринг-системами,
  • Node.js международными модулями.

Эта интеграция требует строгого согласования поведения между спецификациями ECMAScript и WHATWG, хотя Intl формально остаётся частью ECMAScript.

Модель стабильности и долговременной поддержки

Intl API относится к категории стабильно расширяемых стандартов. Его развитие происходит без радикальных изменений, за счёт:

  • добавления новых классов вместо изменения старых,
  • расширения параметров без изменения поведения по умолчанию,
  • сохранения семантики уже опубликованных методов.

Такая модель позволяет использовать Intl в долгоживущих системах без риска деградации совместимости при обновлении движка или спецификации.

Оглавление