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

Что именно меняется для местного посетителя

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

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

Почему перевод интерфейса проверяется только наполовину

Смена языка в переключателе — это фронтенд. Валюта, налог, доставка и каталог — это бэкенд-логика, завязанная на гео IP, а иногда и на ASN: часть сервисов ценообразования различает домашний адрес и дата-центровый, показывая офисному прокси другую версию страницы, чем обычному пользователю. Проверка «текст переведён, кнопки на месте» отвечает на вопрос про язык, но не отвечает на вопрос про то, что реально увидит клиент в нужной стране. Разница между резидентным и мобильным адресом в такой проверке тоже важна — подробнее в статье мобильные против резидентных прокси.

Чек-лист проверки локали

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

Шестое — язык интерфейса и формат дат, чисел, телефонных масок: они должны соответствовать локали, а не только переключателю языка. Проверять эти пункты нужно системно, а не выборочно — методика проверки качества прокси описывает, на какие метрики опираться, чтобы результат был воспроизводим.

Типичные баги локализации, видимые только с местного адреса

Первый — цена в ценнике на 15–20% ниже или выше реальной, потому что налог применяется или не применяется в зависимости от страны IP, а не от адреса доставки, указанного в форме. Второй — кнопка оформления заказа активна, но при попытке доставки в реальный регион всплывает ошибка на последнем шаге: с рабочего IP этот путь никто не проходит. Третий — товар виден в каталоге с домашнего IP разработчика, но пропадает при заходе с адреса целевой страны из-за регионального гейта, о котором никто не знал. Четвёртый — валюта переключается по языку, а не по стране, и франкоязычный пользователь из Канады видит цены в евро вместо канадских долларов.

Такие баги не ловятся ни ручным QA с офисного IP, ни автотестами без гео-подмены: нужен реальный выход из целевой страны, а лучше — с нескольких типов адресов, потому что часть площадок обрабатывает дата-центровый IP иначе, чем резидентный. Для понимания, какой тип адреса выбрать под задачу проверки, полезен разбор где экономия на прокси мнимая.

Сколько трафика уходит на проверку локали

Полная страница каталога с изображениями — 2–5 МБ, текстовая страница без медиа — 0,3–1 МБ. Проверка сотни карточек товара на предмет цены, налога и доступности доставки укладывается примерно в 0,3–0,5 ГБ, а ежедневный мониторинг сотни страниц по нескольким странам — в 1,5–3 ГБ в месяц. Экономия достигается отключением автозагрузки изображений и шрифтов при автоматической проверке, а не выбором самого дешёвого канала: сорванная сессия из-за нестабильного адреса обходится дороже сэкономленных гигабайт.

Частые вопросы

Хватит ли дата-центрового IP для проверки локализации?

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

Нужен ли адрес именно того города, где живёт целевой пользователь?

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

Как часто нужно перепроверять локализацию, если сайт уже проверен?

Логика ценообразования, налогов и каталога меняется независимо от релизов интерфейса — поставщик обновил прайс, изменилось налоговое правило, добавился региональный гейт. Разумная периодичность — раз в 2–4 недели или сразу после любого изменения ценовой или каталожной логики.

Проверить локализацию своими глазами можно с прокси нужной страны — каталог адресов и типов доступен в разделе прокси.