Многовалютность и мультиязычность маркетплейса — это не «галочки» в списке фич, а системная работа, которая влияет на архитектуру базы данных, платёжный процессинг, SEO и UX одновременно. Если заложить их с первого спринта, доработки обойдутся в разы дешевле, чем retrofit спустя год. Ниже — практическая карта того, что нужно предусмотреть и в каком порядке.
Почему нельзя добавить мультиязычность «потом»
Распространённый сценарий: маркетплейс запускается на русском, через год владелец хочет добавить английский и казахский. Оказывается, что контент товаров хранится в одной таблице без языковых колонок, URL-структура не предусматривает локали, а письма транзакций жёстко захардкожены. Переработка занимает 3–4 месяца и стоит сопоставимо с первоначальной разработкой.
Правильный подход — проектировать схему данных с учётом локализации с нуля. Это означает:
- Отдельные таблицы переводов для каждой сущности (товар, категория, атрибут).
- Locale-aware роутинг:
/ru/,/en/,/kz/или через доменыexample.kz. - Переменные в шаблонах писем и пуш-уведомлений с подстановкой языка пользователя.
- Отдельный pipeline для перевода контента продавцов (машинный + ручная верификация).
Добавить язык в такую систему занимает 1–2 недели, а не месяцы.
Архитектура мультиязычного контента
Есть два основных паттерна хранения переводов.
Паттерн Translation Table
Каждая сущность имеет основную таблицу и связанную таблицу переводов. Например, products и product_translations (product_id, locale, name, description). Плюс: чистая нормализация, легко добавить язык. Минус: JOIN на каждый запрос, нужно кешировать агрессивнее.
Паттерн JSONB-колонка
Все переводы хранятся в одном JSON-поле: {"ru": "Кроссовки", "en": "Sneakers"}. Плюс: один запрос без JOIN. Минус: сложнее индексировать и делать полнотекстовый поиск по конкретному языку. Подходит для небольших маркетплейсов с 2–3 языками.
Для проектов с 5+ языками и высокой нагрузкой рекомендуем Translation Table + Redis-кеш на уровне локали.
Многовалютность: платежи, цены и курсы
Многовалютность в маркетплейсе — это три разных слоя, которые часто путают.
| Слой | Что включает | Ключевой риск |
|---|---|---|
| Отображение цен | Конвертация по курсу ЦБ или фиксированный курс | Расхождение с реальной ценой покупки |
| Приём платежей | Эквайринг в валюте покупателя | Не все PSP работают с нужными валютами |
| Выплаты продавцам | Конвертация и вывод в валюте продавца | Курсовые потери, комплаенс |
Отображение цен. Самый простой вариант — показывать цену в валюте пользователя по текущему курсу, но списывать в базовой валюте платформы. Покупатель видит «≈ $42», но оплачивает в рублях. Это снижает конверсионные барьеры без усложнения финансовой модели.
Реальный мультивалютный эквайринг нужен, когда покупатели физически находятся в другой стране и платят картами местных банков. Здесь подключают Stripe (для международных рынков), Checkout.com или локальные агрегаторы. Важно: каждый PSP имеет свой список поддерживаемых валют и стран — проверяйте до начала интеграции.
Выплаты продавцам. Если продавец из Казахстана хочет получать тенге, а платформа работает в рублях, нужен либо партнёр-агрегатор с мультивалютными выплатами (например, Payoneer, Hyperwallet), либо собственный счёт в каждой валюте. Второй путь — операционно тяжёлый и требует юридического присутствия.
SEO для мультиязычного маркетплейса
Мультиязычность без правильного SEO-фундамента — деньги на ветер. Основные требования:
- hreflang-теги на каждой странице: указывают поисковику, какая версия для какой локали. Ошибки в hreflang — одна из самых частых причин каннибализации трафика.
- Отдельные URL для каждого языка: поддиректории (
/en/) предпочтительнее параметров (?lang=en). Поддомены (en.example.com) тоже работают, но сложнее в управлении. - Уникальный контент для каждой локали, а не машинный перевод «как есть». Google умеет определять дублированный машинный перевод и понижает такие страницы.
- Sitemap с разбивкой по языкам: отдельный sitemap для каждой локали или один с указанием
xhtml:link.
Отдельная история — мультиязычный поиск внутри маркетплейса. Elasticsearch поддерживает language analyzers: для русского это морфологический анализатор, для арабского — свой. Если использовать один универсальный анализатор, качество поиска падает на 30–40%.
UX: переключение языка и валюты
Несколько принципов, которые работают на практике:
- Автоопределение по IP и Accept-Language — хорошая отправная точка, но всегда давайте пользователю возможность переключиться вручную и сохраняйте выбор в профиле или cookie.
- Не смешивайте язык и валюту в одном селекторе. Русскоязычный пользователь в Германии может хотеть интерфейс на русском, но цены в евро.
- Переключение языка не должно сбрасывать корзину и фильтры — это раздражает и снижает конверсию.
- RTL-языки (арабский, иврит) требуют отдельной CSS-стратегии. Используйте логические свойства CSS (
margin-inline-startвместоmargin-left) — это упрощает поддержку RTL.
Если вы планируете разработку маркетплейса с прицелом на несколько рынков, UX-аудит мультиязычного сценария лучше проводить ещё на этапе прототипа — исправить логику переключения в готовом продукте дороже.
Чек-лист перед запуском мультиязычного и мультивалютного маркетплейса
- Схема данных поддерживает переводы без структурных изменений при добавлении языка.
- URL-структура с локалями согласована и задокументирована.
- hreflang-теги настроены и проверены в Search Console.
- PSP поддерживает все целевые валюты и страны.
- Модель выплат продавцам протестирована в тестовой среде.
- Транзакционные письма, пуши и SMS переведены на все языки.
- Поисковый движок настроен с language analyzers под каждую локаль.
- Переключение языка/валюты не сбрасывает сессию пользователя.
- RTL-языки проверены на всех ключевых экранах (если применимо).
- Юридические документы (оферта, политика конфиденциальности) переведены и соответствуют законодательству целевых стран.
Часто задаваемые вопросы
Сколько стоит добавить мультиязычность в уже работающий маркетплейс?
Зависит от исходной архитектуры. Если схема данных изначально не предусматривала переводы, retrofit обходится в 200–600 часов разработки — это рефакторинг моделей, миграция данных, переработка шаблонов и тестирование. Если архитектура правильная, добавление одного языка занимает 40–80 часов: перевод контента + настройка роутинга + SEO-теги.
Можно ли использовать автоматический перевод для контента продавцов?
Да, но с оговорками. Машинный перевод (DeepL, Google Translate API) хорошо справляется с техническими описаниями, но ошибается на сленге, брендовых названиях и специфических категориях. Оптимальная модель: автоперевод как черновик + верификация модератором для топ-категорий + возможность продавцу самому отредактировать перевод. Полностью автоматический перевод без проверки снижает доверие покупателей и ухудшает SEO.
Какой платёжный шлюз выбрать для международного маркетплейса?
Универсального ответа нет — выбор зависит от географии и модели выплат. Stripe поддерживает 135+ валют и маршрутизацию платежей между продавцами (Stripe Connect), но недоступен для российских юрлиц напрямую. Для рынков СНГ часто используют CloudPayments или ЮKassa с мультивалютными счетами. Для Казахстана — Kaspi или Halyk. Оптимально подключить 2 PSP: основной и резервный, чтобы не терять транзакции при сбоях.
Если вы проектируете платформу с выходом на несколько рынков, важно заложить правильную архитектуру до написания первой строки кода. Команда разработки маркетплейса в Aris.Web помогает выбрать стек, спроектировать схему данных и подключить нужные платёжные шлюзы под конкретную географию. Обсудите проект с нами: +7 (977) 326-69-09 или оставьте заявку на странице контактов.