Локализация дат, чисел и валют — это адаптация форматов данных к языку, стране и контексту пользователя. Она нужна, чтобы человек без дополнительного расшифровывания понимал срок, цену, объём, час встречи и единицу сравнения. Это не косметическая замена разделителя или символа валюты: одна и та же строка может менять коммерческий смысл в зависимости от locale, часового пояса, рынка и способа покупки.
Международный сайт теряет доверие, когда пишет 10/08/2026 без пояснения, смешивает десятичную точку и запятую, показывает долларовый знак без кода валюты или переводит время вебинара без часового пояса. Ошибка особенно опасна в цене, сроке подачи заявки, бронировании, контрактной дате и технической спецификации. Надёжная система разделяет исходное значение, правила форматирования и редакционный контекст.
Что именно нужно локализовать
В международном интерфейсе локализуются не только текстовые подписи. Даты, календарь, время, числа, проценты, валюты, единицы измерения, имена и адреса подчиняются разным соглашениям. Unicode Common Locale Data Repository — CLDR — хранит данные и правила, которые используются многими программными платформами для такого форматирования.
Сначала составьте реестр динамических и статических значений:
- дата публикации, обновления, события, дедлайна и доставки;
- локальное время, часовой пояс и переход на летнее или зимнее время;
- цены, диапазоны, налоги, скидки и валюта расчёта;
- десятичные числа, проценты и разряды;
- длина, вес, температура, площадь и другие единицы;
- номера телефонов, почтовые адреса и форматы имени;
- числовые значения внутри изображений, PDF и писем;
- данные, которые передаются из формы в CRM, календарь или платёжную систему.
Такой реестр показывает, где значение приходит из системы и должно форматироваться программно, а где оно вручную написано в статье, рекламном баннере или презентации. Эти два слоя требуют разных владельцев и проверок.
Locale — это больше, чем язык
Язык отвечает на вопрос, на каком языке написан интерфейс. Locale уточняет региональные соглашения: как записывать дату, группировать разряды, показывать валюту и выбирать календарные или числовые формы. Английский для США и английский для Великобритании — не один формат. Французский во Франции и французский в Канаде также могут различаться.
Нельзя автоматически выводить locale только из IP-адреса. Человек может находиться в поездке, использовать корпоративную сеть или покупать для другого рынка. Лучше дать разумный вариант по умолчанию, явно показывать выбранные язык, регион и валюту и позволять изменить их без потери страницы и введённых данных.
Свяжите это решение с архитектурой hreflang, языка, региона и canonical. Поисковая версия страницы и интерфейсное форматирование решают связанные, но разные задачи. hreflang помогает направить пользователя к релевантной версии; locale помогает корректно показать данные внутри неё.
Даты: уберите двусмысленность
Короткая запись вроде 03/04/2027 может означать 3 апреля или 4 марта. В критичных местах используйте месяц словом или формат, который однозначен для выбранной аудитории. Для машиночитаемых данных, интеграций и атрибутов datetime храните стандартное ISO-значение, а пользователю показывайте локализованную форму.
Разделяйте несколько типов даты:
- календарная дата без времени, например дата публикации;
- момент времени, который должен переводиться между часовыми поясами;
- локальное время, привязанное к месту проведения;
- период с началом и окончанием;
- ориентировочный срок, а не подтверждённое обязательство.
Дата события должна сопровождаться статусом, если она ещё может измениться. Не превращайте «предварительно», «приём заявок ожидается» или «дата будет объявлена» в конкретный подтверждённый срок ради удобного заголовка. Для материалов об актуальных событиях проверяйте дату по первичному источнику и указывайте дату проверки.
Время и часовые пояса: храните момент, показывайте контекст
Для онлайн-встречи храните точный момент времени и исходный часовой пояс. Затем показывайте пользователю его локальное время, но оставляйте рядом исходную зону или город, если ошибка может привести к пропуску события. Сокращения вроде CST или IST могут быть неоднозначными; надёжнее использовать город, смещение и полное название зоны.
Переход на летнее и зимнее время означает, что постоянная разница между городами не всегда существует. Нельзя вручную прибавить два часа к дате будущей встречи и считать результат стабильным. Используйте базы часовых поясов и форматирование, которое учитывает правила на конкретную дату.
Для физических событий полезная запись отвечает на четыре вопроса: какая дата, какое местное время, где проходит событие и относится ли время к месту проведения. Для формы заявки добавьте календарное приглашение только после подтверждения, чтобы предварительный запрос не выглядел как назначенная встреча.
Числа и проценты: отделите значение от строки
В одних рынках десятичным разделителем служит точка, в других — запятая. Символ группировки разрядов тоже различается: запятая, точка, пробел или неразрывный пробел. Если число хранится как готовая строка, его трудно корректно сортировать, пересчитывать и форматировать.
Храните числовое значение отдельно и передавайте форматирование интерфейсу. Одновременно задайте точность: сколько знаков после запятой действительно нужно, как округлять, что делать с очень маленькими значениями и как обозначать диапазон. Маркетинговая команда не должна самовольно округлять техническую характеристику, если изменение влияет на обещание продукта.
Процент требует указания базы сравнения. Фраза «рост на 20%» неполна без периода, метрики и исходной точки. Локализованный формат не исправит слабое утверждение. Свяжите число с системой доказательств международного бренда: источник, период, рынок, методика, владелец и срок следующей проверки.
Валюта: код важнее знакомого символа
Символ $ не говорит, идёт ли речь о долларах США, Канады, Австралии или другой валюте. В международном контексте используйте код ISO, когда двусмысленность влияет на решение: USD, CAD, AUD. Символ и код можно сочетать в зависимости от интерфейса и ожиданий рынка.
Разделите три вопроса:
- В какой валюте компания фактически выставляет счёт?
- В какой валюте пользователь хочет видеть ориентир?
- Кто и по какому курсу выполняет пересчёт?
Показ конвертированной цены не означает, что расчёт будет произведён в этой валюте. Если используется ориентировочная конверсия, укажите источник курса, время обновления, возможные комиссии и валюту окончательного списания. Для оферты, налога и платёжных условий нужна проверка специалистами соответствующего рынка.
Материал о локализации цен для зарубежного рынка помогает определить ценовую логику и единицу сравнения. Техническое форматирование начинается после этого решения, а не заменяет его.
Единицы измерения: переводите решение, а не только символ
Длина, вес, температура, площадь и объём могут требовать другой системы единиц. Простая замена подписи без пересчёта создаёт ошибку; автоматический пересчёт без правил округления может создать ложную точность. Для каждого параметра задайте исходную единицу, допустимую рыночную единицу, коэффициент, точность и ответственного владельца.
Иногда обе единицы нужны одновременно. Это полезно в технической документации, международной логистике или сравнении продукта. Приоритетная единица должна соответствовать рынку, а вторичная — помогать сопоставлению. Не перегружайте интерфейс двумя системами в каждом абзаце, если пользователь принимает решение только в одной.
Проверьте изображения, таблицы, инфографику и загружаемые файлы. Единицы часто остаются внутри графики и обходят основной процесс локализации. Альтернативный текст, подпись и структурированные данные должны сообщать то же значение, что и видимый материал.
Формы и CRM: не ломайте данные на входе
Форма заявки может показывать локальный формат, но сохранять нормализованное значение. Пользователь вводит привычную дату или телефон, система проверяет её в контексте выбранного рынка и передаёт в CRM данные в устойчивом формате. Ошибка валидации должна объяснять, что именно ожидается, а не просто отклонять запись.
Не заставляйте международного пользователя помещать регион, индекс или отчество в структуру одной страны. Руководство W3C по формам отдельно обращает внимание на различия имён, адресов и телефонных номеров. Собирайте только те поля, которые нужны для ответа и обработки запроса.
После изменения формы проверьте весь маршрут: видимый интерфейс, сообщение об ошибке, подтверждение, письмо, CRM, календарь и отчёт аналитики. Практический контекст есть в статье о локализации формы заявки.
Контент, код и дизайн должны использовать один стандарт
Редакционный гайд задаёт, как писать статические даты, суммы, диапазоны и единицы. Компоненты сайта форматируют динамические значения. Дизайн определяет место для длинных названий месяцев, кодов валют и двух строк времени. Если эти три слоя проектируются отдельно, интерфейс будет выглядеть согласованно только на исходном языке.
Создайте таблицу решений:
| Элемент | Исходное значение | Правило показа | Владелец |
|---|---|---|---|
| Дата публикации | ISO date | locale страницы | редакция |
| Время события | UTC + IANA zone | локальное + исходная зона | координатор |
| Цена | число + валюта расчёта | locale + код при риске двусмысленности | коммерческий отдел |
| Процент | число + база | локальный формат + источник | аналитик |
| Единица | значение + исходная единица | рыночная единица + правило округления | продукт |
Такой реестр можно включить в управление международным контентом и локализацией. Он снижает число ручных исключений и помогает быстро обновлять значения во всех версиях.
QA: проверяйте сценарий, а не набор строк
Автоматическая проверка должна находить отсутствующий locale, неверный тип данных, невалидную дату и формат, который не помещается в компонент. Ручная проверка должна пройти через реальные сценарии: прочитать цену, выбрать дату, отправить форму, получить письмо, добавить встречу в календарь и увидеть запись в CRM.
Используйте граничные значения: первый и последний день месяца, полночь, переход времени, отрицательное число, ноль, крупную сумму, диапазон, валюты с разным числом дробных знаков и языки с длинными названиями. Проверяйте мобильный экран и увеличение текста. Значение не должно обрезаться там, где оно влияет на решение.
Полезно измерять ошибки формы, возвраты к полю, отменённые платежи, обращения в поддержку и расхождения между выбранным рынком и валютой. Эти сигналы не доказывают причину сами по себе, но показывают, где формат может создавать сомнение.
Минимальный план внедрения
Начните с страниц и действий, где ошибка стоит дороже всего: форма заявки, цена, дедлайн, событие, расчёт и техническая спецификация. Зафиксируйте исходные значения, locale, часовые пояса, валюты расчёта и владельцев. Затем вынесите динамическое форматирование в общие компоненты и добавьте редакционные правила для статического контента.
После выпуска протестируйте две контрастные локали, например английский для США и французский для Франции, а затем добавьте рынки, которые требуют других календарных, адресных или письменных соглашений. Масштабируйте систему только после того, как путь от страницы до CRM воспроизводится без ручного исправления.
Обсудить задачу
Если международный сайт смешивает форматы, локальные версии собираются вручную, а формы и CRM по-разному понимают даты, валюты или телефоны, ICON IMAGE может провести аудит клиентского пути и локализационной системы. Через форму контакта направьте рынки, языки, ключевые URL, примеры ошибок и ближайший запуск. Мы определим, какие решения относятся к стратегии, контенту, интерфейсу и технической реализации, и соберём единый стандарт для команды.