Региональные данные Intl и переносимое форматирование в браузере

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

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

Региональные данные браузера могут меняться вместе с обновлением среды выполнения, а детали отображения могут различаться. Цель совместимости не в том, чтобы везде была одинаковая пунктуация. Важно, чтобы человек понимал значение, при необходимости выбирал подходящий язык или регион и мог выполнить задачу. Отдельный вопрос согласованности языка и часового пояса браузера рассматривается в руководстве о часовых поясах, регионе и языке. Здесь речь идёт о выводе приложения, а не об идентичности браузера.

Позвольте пользователю выбрать язык отображения

Браузер может сообщить языковое предпочтение, но приложению не следует считать этот сигнал окончательным решением. Люди делят устройства, путешествуют, работают на разных языках или предпочитают отдельные языки для разных задач. Язык учётной записи также может быть полезнее текущего предпочтения браузера. Выберите начальный вариант отображения по доступным данным и предоставьте заметную возможность изменить его, если язык важен для задачи.

Разделяйте язык интерфейса и регион форматирования, когда продукту важно это различие. Человек может читать инструкции по-английски, но ожидать регионального формата дат и цен. Другой пользователь может выбрать язык содержимого, не желая менять валюту выставления счетов в учётной записи. Приложение должно называть предлагаемый выбор. Элемент «Язык» не должен незаметно менять валюту суммы или исходный часовой пояс события.

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

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

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

По возможности согласуйте язык содержимого с форматированием, но не заставляйте одно значение решать все задачи. Сообщение на испанском может содержать сумму в формате региона выставления счёта и время встречи в часовом поясе, выбранном читателем. Указывайте, какой выбор управляет каждым значением. Это яснее, чем считать языковое предпочтение браузера полным профилем человека.

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

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

О взаимодействии выбора браузера, учётной записи, сайта и сети рассказывает руководство о конфиденциальности совокупности браузерных поверхностей. Языковое предпочтение является входом для отображения. Его объединение с несвязанными сигналами для классификации пользователей представляет собой другое применение данных и не относится к обычному форматированию.

Используйте Intl для отображения, а не как источник истины

Intl предоставляет JavaScript-приложениям средства форматирования и другие языковые службы. ECMA-402 определяет их поведение и модель региональных операций. MDN описывает распространённые интерфейсы форматирования и их использование в приложениях. Браузер предоставляет реализацию и региональные данные. Приложение передаёт значение, подходящие параметры и контекст отображения результата.

Храните канонические данные в типах и полях, отражающих их смысл. Денежной сумме нужны числовое значение и отдельный код валюты. Запланированному событию нужен момент времени или чёткое правило местного времени и применимый часовой пояс. Для измерения нужны значение и единица. Отформатированная строка не может надёжно вернуть все эти поля в хранилище, поскольку пунктуация, символы, порядок и язык различаются.

Форматирование обычно является последним этапом перед отображением. Служба данных может вернуть структурированные значения, а страница применить выбранные читателем варианты представления. Это позволяет менять язык интерфейса без переписывания сохранённой записи. Ясными становятся и правила экспорта: машиночитаемый экспорт сохраняет структуру данных, а отчёт для людей может содержать локализованные подписи и формат.

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

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

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

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

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

Форматируйте числа, деньги и даты с учётом контекста

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

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

Храните код валюты вместе с суммой. Регион может изменить порядок символа, пробелы и группировку цифр, но не определяет валюту транзакции. Смена языка читателя не должна незаметно конвертировать сумму или помечать её другой валютой. Если предлагается конвертация, это отдельная операция; продукту следует объяснить источник курса и время его действия.

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

Дате нужны и значение, и решение о часовом поясе. Зарегистрированный в системе момент можно показывать в зоне читателя, месте события или постоянной отчётной зоне. Это разные значения для продукта. Языковой тег меняет текст и порядок частей даты, но сам по себе не выбирает зону встречи или юридического срока.

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

Переходы на летнее время делают небрежные предположения особенно ненадёжными. Местное время может повториться или отсутствовать в день перехода. Приложение для планирования событий должно разрешать это по документированному правилу; форматирование отметки времени является только этапом отображения. В обычном показе добавляйте название зоны или смещение, если людям нужно сравнить время в разных местах. Не заставляйте их выводить зону из языка или местоположения.

Граница API конкретна: Intl.Locale обрабатывает идентификаторы локали, Intl.NumberFormat представляет числа и валюты, а Intl.DateTimeFormat представляет дату и время. Эти API не выбирают валюту транзакции, не определяют календарный день и не разрешают правило планирования приложения.

Корректность часовых поясов требует целевых проверок приложения, особенно для поездок, повторяющихся событий и переходов на летнее время. Держите эту предметную логику отдельно от общего слоя форматирования. В статье о согласованности JavaScript Math в браузерах рассматриваются числовые вычисления и переносимость, но она не заменяет определение смысла даты, валюты или единицы перед показом.

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

Учитывайте различия региональных данных и среды выполнения

Поведение Intl зависит от договора ECMA-402 и региональных данных, доступных в среде выполнения. Спецификация задаёт алгоритмы и обязательное поведение, но не фиксирует навсегда каждое слово, сокращение и типографскую деталь каждого языка для всех будущих выпусков. Региональные нормы меняются. Браузер или операционная система могут получить новые данные без изменения кода приложения.

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

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

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

Региональные данные не являются источником сведений о личности. Выбор определённого сокращения средой не доказывает место жительства или язык человека. Приложению не следует классифицировать пользователей по результату форматирования. Используйте явные предпочтения и сведения задачи, а диагностику совместимости ограничивайте относящимся к продукту результатом.

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

Учитывайте копируемые и экспортируемые сведения. Число из подписанной таблицы может стать неоднозначным без заголовка. В экспорт и функцию отправки добавляйте единицу, валюту, часовой пояс даты и другой необходимый контекст. Для машиночитаемых экспортов задавайте явную схему и оставляйте локализацию принимающему интерфейсу, а не экспортируйте один лишь текст отображения.

Если обновление браузера меняет вывод, прежде чем называть это регрессией, оцените последствия для пользователя. Изменился смысл суммы, стала нечитаемой подпись или поменялись только пробелы? Зависело ли приложение от фиксированной строки, которую платформа никогда не обещала сохранять? Ограниченный набор примеров для реальных задач помогает ответить лучше, чем сбор каждого варианта форматирования.

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

Делайте форматирование понятным и доступным

Локализованную строку нужно понимать в контексте. Короткая цифровая дата компактна, но может быть неоднозначной. Числу с разделителями групп и дробной части всё равно нужна подпись. Валюта, единица и часовой пояс должны быть видны в момент решения, а не спрятаны в подсказке, которая может быть недоступна вспомогательным технологиям.

Для текста рядом с форматированным значением используйте семантические элементы страницы. Заголовок таблицы может назвать сумму или дату. Подпись поля формы указывает разрешённый формат ввода, а сообщение состояния объясняет изменение предпочтения. Такая структура помогает программам чтения с экрана и другим средствам связать значение со смыслом. Само форматирование не создаёт отсутствующие в разметке отношения.

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

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

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

Проверяйте вспомогательные технологии и размеры текста, используемые аудиторией. Убедитесь, что длинные локализованные значения переносятся, не закрывая соседние элементы, порядок чтения остаётся разумным, а скопированному значению хватает контекста вне страницы. Если значение визуально сокращено, предоставьте полную доступную форму, когда это повышает ясность. Не создавайте лишние повторные объявления.

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

Лучшая проверка приёмки основана на настоящей задаче. Может ли человек понять сумму и валюту до подтверждения оплаты? Понятно ли участнику, когда начинается событие и какой часовой пояс действует? Можно ли сменить язык без потери работы? Эти результаты важнее воспроизведения каждого символа одной среды выполнения.

Проверяйте форматирование как договор продукта

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

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

Для синтетического примера денежной суммы отформатируйте значение 1234.5 как EUR с представлением en-GB, явным кодом валюты и двумя цифрами после запятой. Пользователь должен увидеть сумму, эквивалентную 1234.50 евро, и обозначение EUR. Изменение пробелов из-за региональных данных не должно проваливать проверку, но изменение суммы или отсутствие метки валюты должно. Если приложение поддерживает только английский и французский, а получает испанское предпочтение, заявленный английский вариант должен показывать ту же сумму и валюту и указывать текущий язык.

Для примера с расписанием сохраните один и тот же момент времени 2026-01-01T01:30:00Z: в UTC это 1 января 2026 года, 01:30, а в America/New_York это 31 декабря 2025 года, 20:30. Оба представления должны указывать часовой пояс и соответствовать одному сохранённому моменту. Пунктуация может различаться, но изменение момента или необъяснённая смена даты означает провал проверки.

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

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

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

Публичные источники

• API интернационализации ECMA-402
• MDN: Intl