Найпоширенішою проблемою багатомовних офіційних сайтів є не переклади з «перекладацьким акцентом», а те, що вихідний текст уже змінено, а на перекладеному сайті досі висить старий матеріал. Китайська сторінка заходу вже запущена, а англійський прайс-лист досі відповідає минулому кварталу; у японському правовому розділі забули оновити одну позицію, і скарги з-за кордону одразу надходять до нас. Основна причина зазвичай полягає в тому, що кожна мова видавається окремо, без загального доступу до «одного й того самого пакета контенту».
Розкладемо проблему: пакет контенту, стан мови, вікно публікації
Дивіться на один переробок як на цілий пакет контенту, а не просто на «зміну кількох сторінок»:
- Вихідний запис мовою: заголовок, основний текст, призив до дії, структуровані поля (ціна, параметри, заява про відповідність)
- Копія для кожної мови: одна запис для кожної мови, із статусом перекладу: очікує на переклад/перекладається/очікує перевірки/готова
- Вікно публікації: набір мов, які можуть бути опубліковані, та єдиний час активування; якщо не готова жодна мова, весь пакет блокується або поступово понижується за заданими правилами
- Точка відкоту: відкот до версії пакету контенту, а не лише до файлу окремої мови
Передача Word‑файлів через онлайн‑диск із подальшим ручним вставлянням — найпростіший шлях втратити поля та посилання. Якщо CMS дозволяє «окреме публікування для певної мови», то виникає напівнова, напівстара версія міжнародного сайту.
Як це треба спроектувати
Ролі: відповідальний за контент (вихідна мова), перекладач/агент, юридична перевірка (для конкретних розділів), менеджер публікації. Поки вихідний текст не завершений, перекладач не має права починати роботу; поки юридичний розділ не перевірений, дана мова не може перейти до стадії готовності. Фронтенд‑кеш відключається за номером версії пакету контенту, щоб уникнути залишків старої сторінки в CDN.
- Пакет контенту: ключові бізнес‑показники, список мов‑цілей, плановий час запуску
- Статті: порівняння полів, скріншоти, посилання на термінологічний довідник
- Правила доступу: обов’язкові мови, мови з можливістю відтермінування, умови блокування
- Записи публікації: оператор, версія, хеш кожного язика
Увага до SEO: hreflang і canonical повинні змінюватися разом з версією; сторінки недоступних мов мають повертати правильний код стану, а не soft 404. Для тимчасових сторінок заходів можна використовувати стратегію «лише вихідна мова + англійська», але це треба явно прописати в правилах доступу, а не покладатися на усне домовлення.
Розробка та приймання
Перекладач може отримати чернетку машинного перекладу, але готовість має підтверджуватися вручну. Структуровані поля (ціна, дата) заборонені для внесення вільного тексту; окремі поля перекладаються, щоб зменшити кількість помилок. Пресервісна середа перевіряється за мовним маршрутом: після зміни ціни у вихідному тексті мови, які ще не готові, не повинні бути доступні для зовнішнього доступу з новою ціною.
Сценарії приймання:
- Що робити, якщо вихідний текст змінив ціну, а англійська мова ще не готова: чи продовжувати показувати стару ціну, чи перейти до повної підтримки сторінки (залежно від стратегії)
- Чи фіксувати випадки примусового публікування, яке обходить правила, і чи потрібна двомісна перевірка
- Чи збігається hreflang після відкоту
- Чи викликає тривале затримання певної мови червону лампочку на панелі управління
- Чи маркувати масово відповідні статті у термінологічному довіднику у разі змін
Дисципліна багатомовного сайту: спочатку всі мови повинні бути готовими, перш ніж з’являтися. Дозволяється повільність, але не допускається напівнова, напівстара версія.
Модель невдачі
Маркетинг спочатку запускається китайською мовою: захід вже розміщений, а перекладений сайт ще не змінився, і зарубіжні клієнти, зайшовши на сайт, відчувають розрив. За стандартними правилами доступу передбачено «повний комплект мов», а в екстрених випадках потрібно отримати схвалення і встигнути доповнити встановлені строки. Прямий машинний переклад: заборонені сторінки законів та цін; опис продукту може бути перекладений машинною системою з вибірковою перевіркою. Технічні стеки окремих мовних сайтів розходяться: правила доступу та номери версій не можуть бути узгоджені, тому головне — зібрати всіх під одним контент‑сервісом.
Що слід перевіряти після запуску
Протягом чотирьох тижнів слідкуйте за: кількістю годин затримки міжмовного контенту, кількістю випадків обходу правил доступу, скаргами клієнтів, пов’язаними зі старими перекладами, а також кількістю відкотів. Якщо затримки та обходи зменшуються, тоді можна говорити про автоматичний переклад усіх сторінок.
Як інтегрувати робочий процес перекладу у правила доступу
Одразу після завершення вихідного тексту запускається завдання перекладу: можна вибрати машинний переклад, але обов’язкова людська перевірка. Перевіряють за розділами, і для сторінок продукту та вакансій можуть бути різні люди. У разі відмови треба вказувати конкретні поля, а не просто писати «ще раз поправте». Після готовності включається розрахунок загального пакету контенту.
Аутсорсери працюють з обмеженим аккаунтом, бачать лише свої доручені завдання, але не мають права безпосередньо публікувати. Порівняння файлів (двомовне порівняння) допомагає зменшити кількість пропущених абзаців. Посилання та alt‑тексти для зображень перевіряються окремо; багато «інцидентів зі старими перекладами» насправді виникають через старі посилання.
Для сторінок з жорсткими вимогами до відповідності (політика конфіденційності, умови договору) перед запуском обов’язково залучається юрист; календар повторних перевірок генерується за мовою, щоб уникнути ситуації, коли англійська зміниться, а китайська забудеться.
Основні технічні моменти реалізації
Контент‑сервіс зберігає версії на рівні полів; при генерації статичного сайту записується список версій, і адміністрація може перевірити, чи збігаються об’єкти CDN. Пресервісна доменна зона повністю відображається за мовою, а скриптів для перевірки ключових URL з цінами та датами.
Якщо використовується база перекладів, при зміні вихідного тексту треба маркувати відповідні записи, щоб уникнути повторного використання старих фраз у новому контексті. У разі конфлікту термінологічного довідника остаточне рішення приймає власник бізнесу, і це заноситься до списку змін.
Рекомендується уникати публікації у години пік; у разі невдачі система автоматично зупиняється на пресервісі, не допускаючи часткового запуску на виробництво. Моніторинг «затримки готовності мов» — важливий KPI для команди контенту, значно важливіший за «кількість опублікованих сторінок».
Шаблон аналізу аварій
Одна типова аварія: китайська мова змінила ціну і опублікувала її, а англійська все ще показувала стару ціну; служба підтримки замкнула замовлення за англійською ціною. У аналізі треба чітко вказати: який пробіл у правилах доступу, хто мав право обійти їх, скільки часу зайняв відкат, який обсяг впливу на клієнтів. Робити «обхід правил доступу» винятковим каналом, який потребує двомісної перевірки, і фіксувати це в протоколі.
Відкоти проводяться раз на квартал: навмисне забруднюють другорядні мови, щоб пройти повний відкат і процедуру повідомлення. Під час таких навчань виявили, що TTL кешу CDN занадто довгий, тому варто заздалегідь скоригувати стратегію, а не чекати справжньої аварії.
Для продажів та служби підтримки відкривається «запит на збіг мов»: вводите SKU продукту, і дивитесь, яка ціна і коли почне діяти для кожної мови. Такий попередній контроль допомагає зменшити кількість скарг, пов’язаних зі скріншотами користувачів.
Інтеграція з маркетинговими кампаніями
URL цільової сторінки, на яку посилаються матеріали кампанії, має бути прив’язана до версії пакету контенту. Рекламні групи для мов, які ще не готові, автоматично призупиняються або переключаються на сторінку технічного обслуговування, щоб не витрачати рекламний бюджет на стару ціну. Рекламні спеціалісти дивляться лише на статус «можна рекламувати», а не самостійно вгадують у CMS.
Після завершення заходу і відключення всіх мов, всі вони одночасно втрачають свою дію; залишки зовнішніх посилань перенаправляються за 301 на загальну сторінку, а копія версії зберігається для подальшого контролю.
Якщо дочірні компанії використовують окремі CMS, принаймні треба узгодити «API стану пакету контенту»: головний маркетинговий центр перевіряє готовність кожного сайту перед запуском реклами. Без такого API правила доступу змушені обмежуватися усним синхронізацією, і рівень аварій не знижується.
Номер пакету контенту заноситься до поля у заявці на послугу підтримки, щоб легко знайти, до якої версії відноситься скарга на старий переклад.