NovФормат числа по языку не должен менять его значение
Как локализация чисел может изменить восприятие суммы и почему языковая версия должна менять представление, но не исходное значение.
Материал отражает практическую позицию указанного эксперта. Как готовятся и проверяются публикации — в редакционной политике NovAsia.
Одно число может выглядеть по-разному в разных языковых версиях и оставаться тем же числом. В этом и состоит нормальная локализация: человеку показывают привычные разделители, порядок валюты и запись дробной части, не меняя экономический смысл. Проблема начинается, когда форматирование перестаёт быть последним слоем представления и незаметно вмешивается в само значение.
Для сайта недвижимости это не мелкая типографика. Цена, площадь, платёж, доходный ориентир или количество единиц часто участвуют в сравнении. Если русская и английская страницы визуально отличаются, пользователь готов это принять. Если из-за локали одна версия фактически показывает другую сумму, это уже две разные сделки, даже если источник был один.
Формат — оболочка, значение — опора
Мне удобнее мыслить числом в двух состояниях. Есть исходное значение, например условные 1 250 000 единиц валюты. Есть его представление для читателя: с разделителями групп, валютным кодом, нужным количеством знаков после запятой и правилами выбранного языка. Представления могут отличаться. Исходное значение — нет.
Такое разделение важно ещё и потому, что форматирование должно быть обратимым в человеческом смысле. Покупатель, переключив язык, должен узнавать ту же сумму. Если он сохранил объект в одной версии и открыл во второй, не должно возникать впечатления, что цена изменилась только из-за языка. Смена записи может менять ритм чтения, но не обязательство.
Unicode CLDR описывает локальные символы для десятичного разделителя, группировки и валютных шаблонов. То есть различие вида — нормальная часть интернационализации. Ошибка появляется не от того, что одна локаль использует другой разделитель, а от того, что приложение начинает путать символ представления с числовым содержанием.
Разделитель способен изменить чтение сильнее, чем кажется
Числа особенно опасны тем, что визуально правдоподобная ошибка может не бросаться в глаза. Условная запись «1,250» в одном контексте воспринимается как тысяча двести пятьдесят, а в другом наборе правил запятая может быть связана с дробной частью. Поэтому выводить голое число без единицы, валюты и контекста рискованно даже тогда, когда технически формат корректен.
На сайте недвижимости я бы не пытался решать эту проблему одним универсальным шаблоном вроде «везде ставим пробел». Пользовательский язык, валюта, единицы площади и назначение числа могут требовать разного представления. Но у системы должен оставаться один устойчивый ответ на вопрос: какое значение стоит за этой строкой.
Это особенно заметно при округлении. Допустим, интерфейс показывает ориентир без дробной части, а расчёт внутри хранит более точное число. Само округление допустимо, если его назначение понятно. Нельзя затем взять уже округлённую строку одной локали, прочитать её как новые исходные данные и на этой базе пересчитать вторую версию. Тогда различие представления начинает накапливаться как различие фактов.
Валюта и единица должны путешествовать вместе с числом
Число без подписи часто невозможно проверить. «85» может означать площадь, цену за метр, этаж, процент или количество квартир. Поэтому локализация не должна рассматриваться отдельно от единицы. Если в русской версии показано 85 м², а в английской — 85 квадратных метров в английском обозначении, меняется надпись, но не измеряемая величина. Если одна сторона вдруг показывает 850 или 8,5, это уже не языковой вопрос.
С валютой ещё важнее не полагаться только на символ. Один и тот же знак может использоваться в разных валютах, а международная аудитория часто читает предложения вне привычного контекста. Код или ясное название валюты помогает сохранить смысл при копировании, снимке экрана и экспорте.
Ошибка обнаруживается лучше в паре версий
Отдельная страница может выглядеть идеально. Поэтому для двуязычного продукта я считаю полезным проверять не только «корректно ли число отформатировано по-русски» и «корректно ли оно отформатировано по-английски», но и «это одно и то же исходное значение?».
Такой тест не требует сравнивать весь текст посимвольно. Тексты должны быть самостоятельными. Сверяются материальные поля: цена, валюта, площадь, количество, дата, процент, результат расчёта и другие значения, от которых зависит решение. Если они имеют общий источник, языковой слой не должен создавать новую реальность.
Полезен и сценарий переключения языка прямо во время выбора. Человек видит карточку, меняет язык, открывает сравнение, возвращается к объекту. В каждом месте значение должно сохранять идентичность. Именно в таких переходах обнаруживаются дефекты, которые не видны при изолированной проверке каждой страницы.
Копирование и экспорт — второй тест локализации
Красивое отображение в браузере ещё не гарантирует, что значение переживёт выход из страницы. Пользователь копирует цену в сообщение, сохраняет подборку, открывает документ в другой системе. Если число существует только как декоративно отформатированная строка, риск неправильного чтения возрастает.
Поэтому я предпочитаю, чтобы экспортируемое представление сохраняло валюту, единицу и достаточный контекст. Дата данных тоже может быть существенной, если значение меняется со временем. Это уже не вопрос «какой разделитель красивее», а вопрос сохранения смысла при переносе.
Локализация сделана хорошо, когда человек замечает удобный язык, но не замечает технической работы за ним. Русская и английская версии могут выглядеть по-разному и звучать по-разному. Материальная сумма, площадь или другой числовой факт при этом должны оставаться одной и той же вещью.
Источники
- Unicode CLDR — Number and Currency Patterns; правила локализованных разделителей, группировки и валютного представления; дата обращения: 6 октября 2026 года.
- Unicode Technical Standard #35, Part 3: Numbers — описание локализованных числовых символов и шаблонов; дата обращения: 6 октября 2026 года.