Мультимовність та мультивалютність PrestaShop: необхідність та вигоди

Налаштування мультимовного та мультивалютного PrestaShop — переклад каталогу, автооновлення курсів валют, коректні hreflang — критичне для виходу на закордонні ринки. Наприклад, клієнт з каталогом 5000 товарів додав польську мову та злотий — конверсія зросла на 25%. Але неправильне налаштування hreflang і дублі контенту могли б зруйнувати SEO. Ми вирішили обидва завдання комплексно. Мультимовність — це не лише переклад інтерфейсу, але й коректні URL для пошукових систем, правильне форматування цін та автоматичне оновлення курсів. Помилка на будь-якому етапі веде до втрати клієнтів і падіння позицій у видачі. Розберемо технічні деталі налаштування, типові помилки та готові рішення для інтернет-магазинів на PrestaShop.

Проблеми, які вирішуємо

• Неповні переклади: товари, категорії, CMS-сторінки — все має бути локалізовано. Інакше — змішування мов в адмінці та на вітрині.
• Некоректне відображення цін: форматування чисел та знаків валюти залежить від локалі. Приклад: 1 299,99 ₽ для ru-RU, $1,299.99 для en-US.
• Ручне оновлення курсів: волатильність валют вимагає автоматизації.
• SEO-штрафи через дублювання контенту: без коректних hreflang та мовних URL Google може вважати сторінки різними мовами дублікатами.

Додавання мов

Мови в PrestaShop відповідають локалям PHP і постачаються з мовними пакетами. Встановлення через CLI:

php bin/console prestashop:language:install ru-RU

Або програмно через об'єкт Language:

$language = new Language();
$language->name        = 'Русский';
$language->iso_code    = 'ru';
$language->locale      = 'ru-RU';
$language->language_code = 'ru-RU';
$language->date_format_lite  = 'd.m.Y';
$language->date_format_full  = 'd.m.Y H:i:s';
$language->is_rtl    = false;
$language->active    = true;
$language->add();

Після активації мови необхідно перекласти:

• інтерфейс (back-office, front-office) — через мовні пакети;
• контент каталогу — через імпорт CSV або програмно.

URL-структура для SEO

PrestaShop підтримує кілька стратегій:

Префіксна стратегія в 3 рази ефективніша за GET-параметри для ранжування — підтверджено дослідженнями Google Search Central. Налаштування в адмінці: International → Localization → додавання мовного префіксу. Для Nginx додатково пропишіть правила rewrite (приклад: rewrite ^/ru/(.*)$ /$1?id_lang=2 last;).

Додавання hreflang через hook displayHeader:

public function hookDisplayHeader(): string
{
    $languages = Language::getLanguages(true);
    $currentController = $this->context->controller;
    $hreflangs = [];

    foreach ($languages as $lang) {
        $url = $this->context->link->getLanguageLink($lang['id_lang']);
        $hreflangs[] = sprintf(
            '<link rel="alternate" hreflang="%s" href="%s">',
            $lang['language_code'],
            $url
        );
    }

    $hreflangs[] = '<link rel="alternate" hreflang="x-default" href="' .
        $this->context->link->getLanguageLink(Configuration::get('PS_LANG_DEFAULT')) . '">';

    return implode("\n", $hreflangs);
}

Налаштування валют

PrestaShop зберігає всі ціни в базовій валюті. Додавання валюти програмно:

$currency = new Currency();
$currency->name          = 'Польський злотий';
$currency->iso_code      = 'PLN';
$currency->iso_code_num  = '985';
$currency->sign          = 'zł';
$currency->conversion_rate = 0.21; // відносно базової (EUR)
$currency->decimals      = 2;
$currency->active        = true;
$currency->add();

Автоматичне оновлення курсів: використовуйте вбудований провайдер або напишіть кастомний (приклад з ЦБ РФ в оригінальній статті). Налаштуйте cron на виконання php bin/console prestashop:currencies:update-exchange-rates кожні 6 годин.

Форматування цін за локаллю

Кожна валюта форматується через CurrencyFormatter:

use PrestaShop\PrestaShop\Core\Localization\Locale\Repository as LocaleRepository;

$locale = $localeRepository->getLocale('ru-RU');
$formattedPrice = $locale->formatPrice(1299.99, 'RUB');
// → "1 299,99 ₽"

$formattedPrice = $locale->formatPrice(99.99, 'EUR');
// → "99,99 €"

Чому варто автоматизувати оновлення курсів?

Ручне оновлення курсів — ризик помилок і втрата прибутку. Вбудований провайдер PrestaShop використовує European Central Bank, але ви можете підключити будь-який API. Порівняння популярних провайдерів:

Обирайте провайдера виходячи з географії — для Росії оптимальний ЦБ РФ. Налаштування cron гарантує актуальність курсів без втручання.

Які інструменти використовувати для масового перекладу?

Переклад каталогу з 10 000 товарів вручну — тижні роботи. Використовуйте:

• CSV імпорт/експорт з колонками для кожної мови.
• Модулі автоматичного перекладу (Google Translate API, DeepL).
• Кастомні скрипти на Symfony Console для пакетної обробки.

Ми надаємо перевагу CSV — дає повний контроль. Приклад структури:

Обсяг робіт при налаштуванні під ключ

1. Аналіз поточної структури та вибір стратегії URL.
2. Встановлення та активація мов, переклад back-office та front-office.
3. Налаштування валют, автооновлення курсів, форматування цін.
4. SEO-оптимізація: hreflang, sitemap, коректні canonical.
5. Масовий переклад каталогу через імпорт/експорт CSV.
6. Тестування та перевірка на реальних замовленнях.
7. Навчання команди роботі з мультимовним контентом.

Після завершення робіт передаємо документацію та надаємо підтримку. Замовте налаштування мультимовності PrestaShop під ключ — ми виконаємо роботу якісно та вчасно.

Орієнтовні терміни:

• Додавання 1–2 мов + переклади back-office: 1 день.
• Налаштування 3–5 валют + автооновлення курсів: 1 день.
• SEO-конфігурація hreflang + URL-структура: 1–2 дні.
• Переклад каталогу 1000–10 000 товарів: 3–7 днів.

Вартість розраховується індивідуально після аудиту. Зв'яжіться з нами для консультації — оцінимо ваш проект безкоштовно. Гарантуємо якість робіт та підтримку після запуску. Зв'яжіться з нами, щоб обговорити деталі вашого проекту.

Розробка інтернет-магазинів

Ми знаємо: інтернет-магазин — це не просто «сайт з кошиком». Це розподілена система управління товарами, інвентарем, замовленнями, платежами, доставкою, поверненнями та комунікацією з клієнтами. Кожен блок має нетривіальну реалізацію, і більшість проблем в e-commerce виникає на стику цих підсистем. Наш досвід — понад 50 реалізованих проектів — показує, що правильна архітектура на старті економить до 40% бюджету на доробках.

Чому продуктивність каталогу деградує при зростанні SKU?

Найчастіша технічна проблема e-commerce — деградація сторінок категорій при збільшенні асортименту. Сторінка працює добре на 500 товарах і починає гальмувати на 10 000. Причини майже завжди одні й ті ж.

N+1 на атрибутах. Завантажуєте список товарів — 50 елементів. Для кожного потрібні категорія, головне фото, ціна з урахуванням знижки, наявність на складі, рейтинг. Без правильного eager loading це 250+ запитів на сторінку. В Laravel вирішується через with(['category', 'mainImage', 'currentPrice', 'stockStatus']) та withAvg('reviews', 'rating'). Але варто з'явитися персональним цінам (b2b) або складським залишкам по регіонах — і одного with() недостатньо. Потрібні Query Object або виділений ReadModel.

Фасетна фільтрація без індексів. Фільтр за кольором + розміром + брендом + діапазоном цін на таблиці в 500 000 записів без складених індексів — це seq scan при кожному запиті. PostgreSQL з правильними індексами тримає фасетну фільтрацію до кількох мільйонів товарів. Для великих каталогів — Elasticsearch або OpenSearch з агрегаціями: вони рахують кількість товарів на фільтр (facet counts) значно швидше.

Пагінація через OFFSET. LIMIT 50 OFFSET 10000 на великій таблиці — погана ідея: PostgreSQL все одно читає перші 10 050 рядків. Keyset pagination (cursor-based) через WHERE id > $last_id ORDER BY id LIMIT 50 працює за постійний час незалежно від сторінки. Як зазначено в документації PostgreSQL, cursor-based pagination гарантує O(log n) при будь-якому зміщенні, що особливо важливо для каталогів із сотнями тисяч товарів.

Конкретний кейс: каталог будівельних матеріалів, 180 000 SKU, фасетна фільтрація по 12 атрибутах. Після переходу з OFFSET-пагінації на курсорну та додавання partial index по (category_id, is_active, price) час відповіді сторінки каталогу знизився з 4,2 с до 280 мс. Економія на серверних ресурсах склала близько 30 000 ₽ на місяць. В іншому проекті (ювелірний маркетплейс) впровадження агрегацій через Elasticsearch скоротило час фільтрації з 8 до 200 мс та заощадило 50 000 ₽ на місяць на інфраструктурі — ще один приклад, як правильна архітектура знижує TCO.

Що таке race condition у кошику та як його уникнути?

Checkout — місце, де гроші або потрапляють на рахунок, або ні. Технічні проблеми тут коштують дорого.

Race condition при резервуванні товару. Два покупці одночасно додають останній екземпляр у кошик і обоє натискають «Оплатити». Без песимістичного блокування або атомарного UPDATE з перевіркою залишку обидва замовлення проходять, інвентар іде в мінус. В PostgreSQL:

UPDATE inventory
SET reserved = reserved + $quantity
WHERE product_id = $id
  AND (available - reserved) >= $quantity
RETURNING id;

Якщо RETURNING повернув 0 рядків — товару немає, показуємо помилку до списання грошей.

Ідемпотентність платіжних вебхуків. payment.succeeded від Stripe або ЮКассы може прийти двічі через мережеві збої або retry-логіку на стороні шлюзу. Без перевірки WHERE NOT EXISTS (SELECT 1 FROM processed_events WHERE event_id = $id) — дублювання замовлення або подвійне зарахування. Webhook idempotency — обов'язковий патерн для будь-якого платіжного інтегратора. Ми включаємо тест на ідемпотентність у стандартний чек-лист кожного проекту.

Checkout у кілька кроків. Multi-step checkout (адреса → доставка → оплата → підтвердження) vs single-page checkout. Дослідження показують, що single-page з прогрес-індикатором конвертує на 15–20% краще на мобільних. Стан між кроками — або localStorage + server-side сесія, або повністю server-side з проміжним збереженням. Ми гарантуємо, що кожне замовлення проходить аудит на ідемпотентність та блокування — це входить у стандартний чек-лист тестування.

Як інтегрувати 1С з інтернет-магазином?

1С — окрема глава. Три поширених способи інтеграції:

1. CommerceML через HTTP — 1С вивантажує XML за розкладом, сайт імпортує. Працює для невеликих каталогів, є затримка синхронізації.
2. REST API / OData від 1С — двостороння синхронізація в реальному часі. Вимагає налаштування на стороні 1С, примхлива до версій конфігурацій.
3. Проміжна шина (RabbitMQ / Kafka) — 1С публікує події, сайт підписується. Найнадійніший підхід для високонавантажених систем, але найдорожчий у розробці.

Служби доставки — СДЕК, Boxberry, Пошта Росії, DHL: всі надають REST API для розрахунку вартості та створення накладних. Агрегатори (Shiptor, Shipnow) дозволяють працювати з кількома службами через єдиний API.

Платіжні шлюзи

Для кожного шлюзу обов'язкова перевірка підпису вебхука — без цього будь-хто може відправити фейковий payment.succeeded.

CMS vs власна розробка

WooCommerce — виправданий для магазинів до ~5 000 SKU з типовою бізнес-логікою. Швидкий старт, величезна екосистема плагінів. Проблеми починаються при нестандартних цінових правилах, складних варіантах товарів або навантаженні від 10 000+ замовлень на місяць. Економія на ліцензії WooCommerce (безкоштовно) обертається витратами на плагіни та хостинг; для каталогу 50 000 SKU місячна вартість підтримки може перевищити 100 000 ₽.

OpenCart, Prestashop — аналогічна історія. Хороші для старту, обмежені при зростанні.

Власна розробка на Laravel — для:

• Нестандартної бізнес-логіки (підписки, оренда, b2b-прайси, конфігуратор);
• Високих вимог до продуктивності;
• Складних інтеграцій (кілька складів, ERP, маркетплейси);
• Унікального UX checkout.

Як ми розробляємо інтернет-магазин: покроковий процес

1. Аналітика та проектування. Збираємо вимоги, уточнюємо бізнес-процеси, моделюємо доменну логіку. На виході — технічне завдання та архітектурна схема.
2. Backend та API. Реалізуємо ядро (товари, кошик, замовлення), інтеграції з 1С/складами/платіжками. Використовуємо Laravel 11 з Repository pattern, чергами для асинхронних операцій.
3. Frontend та checkout. Налаштовуємо React 18 / Next.js 14 з оптимізованим рендерингом (SSR/SSG для каталогу), єдиний single-page checkout.
4. Тестування. Перевіряємо race condition, ідемпотентність вебхуків, навантажувальне тестування (k6), security-аудит.
5. Деплой та моніторинг. Розгортаємо на Vercel / Docker / виділеному сервері, підключаємо Sentry та Uptime.

SEO для e-commerce

Canonical та дублювання. Фасетна фільтрація генерує тисячі URL (?color=red&size=M&sort=price). Без canonical або noindex на фільтрованих сторінках краулінговий бюджет витрачається на дублі, а основні сторінки індексуються гірше.

Structured data. Product schema з offers, aggregateRating, availability — це rich snippets у видачі: зірочки рейтингу, ціна, наявність. Впливає на CTR.

Core Web Vitals на сторінках товарів. Hero image товару — це LCP element. fetchpriority="high" на першому зображенні, правильні srcset з WebP, width та height атрибути для запобігання CLS.

Що входить у результат роботи

Після завершення проекту ви отримуєте:

• Вихідний код та повну документацію (API, архітектура, інфраструктура);
• Доступи до репозиторію, хостингу, моніторингу (Sentry, Uptime);
• Навчання команди роботі з адмін-панеллю та кастомізаціями;
• Гарантійну підтримку 3 місяці (виправлення помилок, консультації);
• Детальний звіт по навантажувальному тестуванню та оптимізації.

Орієнтири за термінами

Вартість розраховується після аналізу вимог: кількість інтеграцій, складність ціноутворення, обсяг каталогу та унікальність UX — основні фактори. Оцінимо ваш проект безкоштовно — замовте консультацію.

Чек-лист перед запуском

• Race condition при оплаті останнього товару — покритий тестом
• Ідемпотентність вебхуків платіжного шлюзу
• Rate limiting на ендпоїнтах кошика та checkout
• Canonical на фільтрованих сторінках каталогу
• Фіскалізація чеків (ФЗ-54 для РФ або аналог)
• Стрес-тест checkout під навантаженням (k6 або Locust)
• Моніторинг помилок (Sentry) та алерти на payment errors
• Backup бази даних з перевіреним restore-процесом

Гарантуємо — кожен проект проходить цей чек-лист перед релізом. Зв'яжіться з нами — підберемо оптимальну архітектуру під ваш бюджет та терміни.