Строгая типизация локалей

Понятие локали как строго ограниченного типа

В системах интернационализации локаль перестаёт быть произвольной строкой и рассматривается как доменно-ограниченное значение. В контексте Globalize локаль базируется на стандарте BCP 47, который задаёт формальный синтаксис языковых тегов: язык, регион, письменность и дополнительные расширения.

Строгая типизация локали означает, что:

  • допускаются только валидные BCP 47 идентификаторы;
  • набор локалей ограничен заранее загруженным CLDR-датасетом;
  • любые операции форматирования и парсинга выполняются только в рамках объявленного множества локалей;
  • недопустимы «молчаливые» fallback-локали без явного контроля.

Такой подход устраняет класс ошибок, связанных с неконсистентными или неподдерживаемыми локалями вроде en_USA, ru-RU-1, english, которые формально не соответствуют спецификации.

CLDR как основа строгой локализации

Архитектура Globalize опирается на CLDR (Unicode Common Locale Data Repository). Это структурированный набор данных, описывающий:

  • правила форматирования чисел и валют;
  • календарные системы;
  • правила множественных форм;
  • локализованные строки и паттерны.

Строгая типизация локалей напрямую связана с загрузкой CLDR-файлов. До момента загрузки данных конкретная локаль считается невалидной в контексте выполнения операций форматирования.

Пример концептуальной модели:

  • есть допустимый набор локалей: ["en", "en-GB", "ru", "ru-RU"];
  • каждая операция требует, чтобы локаль присутствовала в этом множестве;
  • отсутствие данных означает ошибку конфигурации, а не fallback.

Проверка локали как типовая операция

В строгой модели локаль проходит проверку на двух уровнях:

1. Синтаксическая проверка (BCP 47)

На этом уровне проверяется:

  • корректность языка (ru, en, de);
  • корректность региона (RU, US, GB);
  • порядок и структура тега;
  • отсутствие запрещённых комбинаций.

Пример допустимых значений:

  • ru
  • ru-RU
  • en-GB
  • zh-Hans-CN

Пример недопустимых:

  • ru_RU (неправильный разделитель)
  • english-US (невалидный язык)
  • ru-RU-123 (некорректное расширение)

2. Семантическая проверка (CLDR поддержка)

Даже корректный BCP 47 тег может быть недопустим, если:

  • для него не загружены CLDR-данные;
  • отсутствуют правила форматирования чисел или дат;
  • не определены множественные формы.

Таким образом, тип «локаль» в Globalize становится пересечением двух множеств: валидного синтаксиса и доступных данных.

Локаль как параметризованный тип

В строгой типизации локаль рассматривается как параметр функций интернационализации.

Формально:

  • Locale = BCP47 ∩ LoadedCLDRSet

В TypeScript-подходах, которые часто используются вместе с Globalize, это может быть выражено через union-типы:

type SupportedLocale = "en" | "en-GB" | "ru" | "ru-RU";

Или через обобщённые ограничения:

function formatNumber(locale: SupportedLocale, value: number): string;

Такой подход превращает локаль в компилируемую гарантию корректности.

Строгая локаль и инициализация Globalize

Одной из ключевых особенностей Globalize является необходимость явной загрузки данных перед использованием локали.

Типовой порядок инициализации:

  1. загрузка CLDR JSON;
  2. регистрация доступных локалей;
  3. создание экземпляра Globalize для конкретной локали;
  4. выполнение форматирования.

Если локаль не была зарегистрирована, возникает ошибка, а не автоматический fallback.

Это критически важно для строгой типизации: система не допускает «неявных» локалей.

Ограничение множества локалей на уровне приложения

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

Пример архитектурного ограничения:

  • backend и frontend используют один список локалей;
  • локали хранятся в конфигурационном модуле;
  • любые попытки использовать неизвестную локаль блокируются.

Такой подход позволяет:

  • исключить runtime-ошибки форматирования;
  • синхронизировать интерфейсы и API;
  • обеспечить предсказуемость интернационализации.

Fallback как запрещённая операция

В слабых моделях интернационализации fallback часто происходит автоматически:

  • ru-RU → ru → en
  • или даже до системной локали

В строгой модели Globalize fallback рассматривается как ошибка конфигурации.

Причины запрета:

  • скрывает отсутствие локализации;
  • создаёт неконсистентный UX;
  • усложняет тестирование;
  • нарушает типовую целостность системы.

Вместо fallback используется явная проверка:

  • если локаль не поддерживается — выбрасывается исключение;
  • если данных нет — процесс сборки считается неполным.

Строгая локаль в форматировании чисел

Форматирование чисел — одна из наиболее чувствительных зон для строгой типизации.

В Globalize числовые форматы зависят от локали:

  • разделитель дробной части;
  • группировка разрядов;
  • правила округления;
  • отображение процентов и валют.

При строгой типизации:

  • локаль должна быть известна на этапе конфигурации;
  • форматтер не принимает произвольные строки;
  • результат всегда зависит от заранее загруженного набора правил.

Пример логики:

  • ru-RU → 1 234,56
  • en-US → 1,234.56

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

Строгая локаль в форматировании дат

Работа с датами усиливает требования к типизации локалей.

Globalize использует CLDR-календарные данные, которые различаются по:

  • порядку компонентов даты;
  • названиям месяцев;
  • форматам времени;
  • календарным системам.

Строгая модель требует:

  • явного указания локали при форматировании;
  • проверки доступности календарных данных;
  • запрета на частично определённые локали.

Пример:

  • ru → 28.05.2026
  • en-GB → 28/05/2026
  • en-US → 05/28/2026

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

Типизация локалей в многомодульной архитектуре

В больших приложениях локаль становится частью глобального контракта между модулями:

  • UI слой;
  • сервисы форматирования;
  • API слой;
  • слой хранения данных.

В строгой системе:

  • локаль передаётся как типизированный параметр;
  • запрещены строковые «произвольные» локали без проверки;
  • используется централизованный реестр локалей.

Globalize в таких архитектурах выполняет роль runtime-валидации поверх compile-time ограничений.

Безопасное расширение набора локалей

Добавление новой локали в строгой системе требует формального процесса:

  1. обновление CLDR данных;
  2. регистрация локали в конфигурации;
  3. добавление в типизированный список;
  4. проверка тестами форматирования;
  5. повторная сборка приложения.

Это превращает локаль из динамического значения в управляемый элемент системы.

Ошибки строгой типизации локалей

На практике строгая модель выявляет несколько классов ошибок:

  • использование локали без загрузки CLDR;
  • несоответствие BCP 47 стандарту;
  • расхождение между backend и frontend списками локалей;
  • попытка использовать fallback вместо явной локали;
  • отсутствие тестового покрытия для новой локали.

Globalize в этом контексте выступает как механизм раннего обнаружения ошибок конфигурации.

Локаль как элемент контрактного программирования

В строгой типизации локаль становится частью контракта:

  • функция форматирования требует валидную локаль;
  • система гарантирует детерминированный результат;
  • любое отклонение считается нарушением контракта.

Такой подход особенно важен в:

  • финансовых системах;
  • международных платформах;
  • аналитических приложениях;
  • высоконагруженных интерфейсах.

Связь строгой типизации локалей и предсказуемости системы

Главный эффект строгой модели заключается в устранении неопределённости:

  • отсутствуют скрытые fallback-ветки;
  • исключены неконсистентные форматы;
  • поведение системы полностью определяется конфигурацией локалей.

Globalize обеспечивает этот эффект через сочетание CLDR-данных, явной регистрации локалей и строгих правил использования BCP 47.

Оглавление