Войти

Главная Новости и статьи01.02 — это 1 февраля или 2 января? Ловушки локализации, которые стоят денег

01.02 — это 1 февраля или 2 января? Ловушки локализации, которые стоят денег

Строка «01.02.2025» в одной стране означает начало февраля, а в другой — начало января. Если интернет-магазин или приложение показывают такую дату без учёта локали, клиент может прочитать её иначе, чем задумано. Такие мелочи редко попадают в техзадание, но именно из-за них возникают возвраты, пропущенные дедлайны и неловкие письма поддержки. Разберём самые частые ловушки локализации и поймём, как их не допустить.

Даты и время: один день, три прочтения

Порядок частей даты зависит от страны. В России, Германии и большей части Европы принят формат «день.месяц.год». В США сначала стоит месяц, поэтому «03/04/2025» там означает 4 марта, а не 3 апреля. В Японии, Китае и Корее порядок обратный: сначала год, затем месяц и день.

С временем та же история. В России, большей части Европы и Латинской Америки привычен 24-часовой формат, а в США, Канаде, Австралии и Индии широко используется 12-часовой с обозначениями AM и PM. Запись «5:00» без пометки в разных странах читается по-разному, и встреча на «пять» может оказаться через двенадцать часов от запланированного.

Чтобы не гадать, в данных и API лучше использовать стандарт ISO 8601 (например, 2025-02-01T14:30). А в интерфейсе выводить дату средствами локали, а не набирать её вручную.

Разделители в числах: запятая там, где точка

Число «1 500,75» в России и «1,500.75» в США — одно и то же значение. В Германии и Бразилии тысячи отделяют точкой, а дробную часть пишут запятой: «1.500,75». В Швейцарии используют апостроф: «1'500.75». В Индии группировка цифр другая: «1,00,000» означает сто тысяч.

Ошибка здесь особенно коварна. Если цена «1.500» задумана как тысяча пятьсот, а система прочитала её как полторы единицы, покупатель увидит разницу только на кассе. Поэтому в коде никогда не склеивайте строки с числами вручную: используйте форматирование по локали и проверяйте разбор чисел при импорте файлов.

Валюты: символ, место и округление

Символ валюты кажется мелочью, но он легко сбивает с толку. Знак «$» используют в США, Канаде, Австралии и нескольких других странах, поэтому без кода валюты «$» может означать доллары любой из них. Именно поэтому в международных контекстах принято указывать трёхбуквенный код по стандарту ISO 4217: USD, EUR, RUB.

Место символа тоже различается. В англоязычных странах пишут «$100», во Франции «100 €» с неразрывным пробелом, в России «100 ₽» или «100 руб.». Иногда ошибка проявляется в переводе: фраза «цена указана с учётом НДС» в одном языке требует другой структуры, и если текст собран из кусков с подставленной суммой, порядок слов ломается.

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

Метрическая и имперская системы

Большая часть мира пользуется метрической системой, но США используют футы, фунты, галлоны и градусы Фаренгейта. В Великобритании дорожные знаки выражены в милях, а молоко продают в пинтах, при этом пинта там больше американской: около 568 миллилитров против примерно 473. Галлон тоже различается по обе стороны Атлантики.

Для интернет-магазина это значит, что габариты товара, вес посылки и объём упаковки нужно выводить в единицах, привычных покупателю, и при этом не потерять точность. Переводчик, работающий с инструкциями, должен понимать, нужно ли переводить единицу или конвертировать значение. Например, если в руководстве указано «10 дюймов», для российского издания разумнее дать «25 см», но при этом сохранить исходную величину в скобках, если она важна для технических характеристик.

Телефоны, адреса и имена в формах

Формы регистрации чаще всего ломаются на трёх полях. Телефон: в России может быть «+7 (999) 123-45-67», в Германии длина номера переменная, и многие шаблоны с жёсткой маской её не пропускают. Лучше использовать поле с выбором кода страны и библиотеку для валидации номеров.

Адрес: в Японии указывают от крупного к мелкому (префектура, город, район, номер квартала), а в России и Европе наоборот. Почтовый индекс в США состоит из пяти цифр, в Великобритании это буквенно-цифровая комбинация. Поле «Индекс, только цифры» отсекает часть реальных адресов.

Имя и фамилия: в Испании и Латинской Америке часто два фамильных имени, в Исландии вместо фамилии используется отчество, а некоторые люди вообще имеют одно имя. Апостроф в фамилии «O'Brien» или дефис не должны вызывать ошибку. Минимальное требование простое: не делайте обязательными два поля там, где это не нужно, и принимайте любые символы Unicode.

Как избежать ошибок: стандарты и проверка

Работа с форматами начинается не на этапе проверки, а на этапе проектирования. Вот что помогает:

Храните даты в ISO 8601, числа без форматирования, валюты с кодом ISO 4217, а вывод оставляйте локали.
Используйте стандартные библиотеки локализации вместо самописных шаблонов, например ICU или встроенные средства платформы.
Передавайте переводчикам контекст: в тексте должны быть понятны единицы, валюта и тип даты, а не только слова.
Тестируйте интерфейс на датах вроде 01.02, 12:00 и 1 000,50 в нескольких локалях, включая те, где порядок отличается.
Привлекайте носителей языка на финальной проверке. Они быстрее заметят, что «пять вечера» написано как «17.00» в местах, где так не говорят.

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