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

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

Как подготовить сайт к локализации: 7 технических ошибок
Схема основных вопросов статьи.

Сначала определите, какую версию сайта вы создаёте

Язык и рынок не совпадают автоматически. Английская версия может предназначаться для деловой аудитории нескольких стран или для конкретного национального рынка. От этого зависят написание слов, денежные обозначения, формат адресов и тон обращений. Если назвать задачу просто «сделать английский», разные участники проекта начнут принимать решения самостоятельно. Исправлять их придётся после сборки, когда отличия проявятся на страницах и в транзакционных сообщениях.

Полезно описать целевую локаль: язык, регион, аудиторию, валюту отображения, часовой пояс для конкретных операций. Это не означает, что нужно создать отдельную копию сайта для каждой комбинации. Архитектуру выбирают по задачам бизнеса. Но команда должна различать язык интерфейса и коммерческие условия: переключение языка само по себе не меняет продавца, доступные способы оплаты или территорию доставки.

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

Ошибка 1. Кодировка работает только на видимых страницах

Проверка кодировки не заканчивается метатегом в HTML. Символ проходит через редактор, API, базу данных, шаблон письма, экспорт и сторонние интеграции. Если одно звено трактует данные иначе, проблема может появиться только после сохранения формы или выгрузки заказов. На тестовой странице всё выглядит нормально, а имя клиента в письме превращается в нечитаемый набор знаков.

Разработчикам следует проверить согласованность обработки Unicode по всей цепочке и корректное объявление кодировки. UTF-8 широко применяется для многоязычного веба, но наличие этой надписи в одном месте не исправляет уже повреждённые данные. Важно протестировать запись и повторное чтение. Для базы данных учитывают конкретный движок, используемые параметры и поддержку нужного набора символов, включая те, которые встречаются в реальных именах и сообщениях.

Тестовый набор должен содержать больше, чем кириллицу и латиницу без диакритики. Добавьте имена с акцентами, китайский текст, длинное название организации, сочетания разных письменностей. Если проект предполагает арабский, отдельно проверьте направление текста. Проверка должна пройти через реальную форму и уведомление. Скриншот правильно отображённой строки в макете не подтверждает, что сайт сохранит и передаст введённые данные без изменений.

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

Ошибка 2. Строки спрятаны в коде и собираются из обрывков

Текст сайта редко хранится в одном месте. Часть находится в CMS, часть в шаблонах, часть в JavaScript, письмах и сообщениях платёжного модуля. Если выгрузить только содержимое страниц, локализация окажется неполной. Особенно легко пропустить ошибки валидации, всплывающие подсказки, пустые состояния, сообщения после отправки формы и подписи элементов, которые появляются только при определённых действиях пользователя.

Перед переводом составьте карту источников строк. Для каждого укажите владельца, формат выгрузки и способ возврата. Строкам нужны устойчивые идентификаторы, чтобы новый перевод попадал в правильное место после обновления. Нельзя полагаться только на исходную фразу: одинаковое слово в меню и платёжной форме может иметь разный смысл. Идентификатор должен помогать различать такие случаи, а не заменять содержательный комментарий.

Отдельная проблема — склейка предложений. Конструкция из отдельных частей «У вас», числа и слова «товаров» кажется экономной, пока не возникают другие формы числа и иной порядок слов. Переводчик получает фрагменты, которые нельзя грамматически согласовать. Лучше передавать сообщение как целую переводимую единицу с обозначенными переменными и использовать механизмы выбора форм, которые поддерживает применяемый стек.

Переменные нужно защищать от случайного изменения и объяснять их значение. Вместо неясного «{x}» полезнее дать понятное имя и пример подстановки. Укажите, будет ли это имя человека, сумма или название товара. Некоторые значения требуют изменения окружающей фразы. Не просите переводчика менять программные токены ради красивого текста: разработчик должен предусмотреть корректную структуру сообщения, а лингвист — предложить языковое решение в этих границах.

Ошибка 3. Макет рассчитан на длину исходного текста

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

Жёсткая высота блока, фиксированная ширина кнопки и запрет переноса часто превращают обычный перевод в отдельную задачу дизайна. Уменьшение шрифта до нечитаемого размера не решает её. Разработчик и дизайнер должны предусмотреть поведение при длинной строке: увеличение высоты, перенос, изменение сетки или согласованный короткий вариант. Какое решение подходит, зависит от назначения элемента и требований доступности.

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

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

Ошибка 4. Даты, числа и деньги переводят как обычные слова

Дата вида 03/04 может означать разные дни в разных соглашениях о записи. Даже если рядом стоит правильный перевод месяца в другом блоке, неоднозначность остаётся. Пользователь может неправильно понять срок доставки или дату мероприятия. Для разработчика здесь важно отделить хранимое значение от отображения, а для маркетолога — проверить, что сообщение понятно человеку без знания внутреннего формата системы.

Даты и числа лучше форматировать средствами, поддерживающими локали, вместо ручной замены разделителей в строке. Но выбор библиотеки сам по себе не определяет бизнес-правила. Нужно решить, в каком часовом поясе показывается время, что считать началом суток и требуется ли указывать зону рядом. Особенно внимательно проверяют события около полуночи, срок действия предложения и бронирования, связанные с конкретным местом.

У суммы есть как минимум числовое значение, валюта и форма отображения. Замена символа рубля на знак евро не является переводом цены и не выполняет пересчёт. Если бизнес действительно продаёт в другой валюте, нужны отдельные коммерческие правила. В переводческом задании следует описать, что сохраняется, что локализуется и кто утверждает итог. Лингвист не должен самостоятельно устанавливать курс, налоговую составляющую или условия продажи.

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

Ошибка 5. Формы признают нормальным только один тип имени и адреса

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

Начните с вопроса, какие данные действительно нужны для операции. Если отчество не участвует в доставке или идентификации в выбранном процессе, обязательность поля требует обоснования. Адрес следует проектировать с учётом обслуживаемых стран, а не всех стран мира сразу. Нельзя обещать универсальность формы без тестов. Но даже ограниченный список рынков должен быть согласован между логистикой, разработкой и локализацией.

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

Не следует молча исправлять имя клиента под привычный формат. Система может нуждаться в отдельном поле для латинского написания, но это должно быть понятным требованием конкретной операции. Объясните пользователю, что ожидается и почему. Переводчик поможет сделать инструкцию ясной, однако решение о необходимых персональных данных принимает владелец процесса с учётом применимых требований, а не автор локализованной подписи.

Ошибка 6. Текст на картинках и в письмах обнаруживают после запуска

Баннер с русской надписью может остаться внутри полностью переведённой страницы. Ещё чаще забывают вложенные PDF, инструкции, изображения таблиц и автоматически формируемые письма. Причина в том, что команда считает объём по полям CMS, а пользователь видит целую услугу. Для него язык баннера, формы и письма относится к одному продукту, даже если внутри компании эти элементы принадлежат разным отделам.

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

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

Шаблоны писем проверяют на реальных подстановках. Короткое тестовое имя не покажет, что происходит с длинным названием организации. Письмо должно сохранять понятную тему, ссылки и последовательность действий. Также проверьте альтернативный текст изображений и доступные названия интерактивных элементов. Пользователь может получать смысл через вспомогательные технологии, поэтому локализация только визуально заметных надписей оставляет часть интерфейса незавершённой.

Ошибка 7. Нет управляемого обмена файлами и проверки в интерфейсе

Таблица «русский — английский» подходит не для каждого проекта. При ручной сборке можно потерять идентификатор, перепутать строки или импортировать устаревшую версию. Особенно трудно отслеживать изменения, когда сайт продолжает развиваться параллельно с переводом. Команда получает несколько файлов с одинаковым названием и разными правками, а последний по времени документ не обязательно содержит все согласованные решения.

Нужно определить один маршрут: выгрузка из конкретной версии, перевод, проверка, импорт, сборка и тестирование. Изменения исходных строк после выгрузки должны попадать в отдельный список. Стабильные ключи помогают обновлять только затронутый контент. Перед импортом проверяют структуру файла, переменные и обязательные поля. Ошибка формата не должна автоматически приводить к публикации пустых значений или подмене исходного языка.

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

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

Как подготовить пакет для переводчика

Передайте тексты в согласованном формате, список целевых локалей и короткое описание продукта. Добавьте словарь утверждённых названий, правила обращения и сведения о том, какие слова не переводятся. Для неоднозначных строк приложите контекст: скриншот, путь пользователя или комментарий разработчика. Фраза «Открыть» может относиться к документу, счёту или меню; без контекста переводчик вынужден выбирать наугад.

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

Назначьте человека, который может отвечать на вопросы и собирать решения разных отделов. Переводчик не должен самостоятельно выяснять, кто отвечает за доставку, платежи или продуктовые обещания. Ответы фиксируют в общем журнале, чтобы их использовали все участники. При обновлениях этот журнал полезнее переписки, где важное решение легко потерять среди уведомлений и обсуждений сроков.

На передаче файлов полезно проверить один короткий цикл до начала большого объёма: выгрузить несколько строк, перевести их, вернуть в систему и открыть результат. Так команда убеждается, что выбранный формат действительно работает. Если обнаружится несовместимость, менять маршрут на пяти строках проще, чем восстанавливать тысячи записей после завершения всей языковой работы.

Как оценивать бюджет без красивых обещаний

Смету разумно делить на подготовку, языковую работу, обработку графики, интеграцию и проверку. Разделение показывает, на каком этапе появляется повторная работа. Если исходник поменялся, затраты затронут перевод и тестирование. Если сломался импорт, причина находится в обмене данными. Это помогает обсуждать ответственность конкретно и не списывать любые технические проблемы на «сложность иностранного языка».

Для пилота выберите несколько разных компонентов: карточку товара, форму, письмо и страницу с длинным текстом. Условный тест на одной простой странице не покажет стоимость всего проекта. Замерьте не только время перевода, но и количество вопросов, обработку файлов и исправления после сборки. На основании пилота можно уточнить смету; выдавать его результаты за гарантированную экономию для любого сайта нельзя.

Если в процессе возникает новая языковая версия, не копируйте автоматически все прежние решения. Часть инфраструктуры можно использовать повторно, но поведение форм, переносов и графики нужно проверить для новой локали. При этом удачно подготовленные ключи, глоссарий и маршрут импорта сохраняют ценность. Экономия появляется из управляемой системы, а не из требования выполнить следующий язык быстрее только потому, что первый уже опубликован.

Что проверить перед открытием версии посетителям

Пройдите путь нового пользователя от первой страницы до целевого действия. Проверьте меню, поиск, форму, ошибки, подтверждение и письмо. Смените язык на внутренней странице и убедитесь, что переход ведёт к ожидаемой версии. Необходимо отдельно проверить работу на мобильном экране, длинные значения, пустые результаты и неуспешные операции. Именно в этих состояниях часто остаются исходные строки.

Для поисковой видимости проверьте доступность страниц, корректность ссылок, заголовки, описания и настройки языковых версий. Конкретная схема URL и разметки зависит от архитектуры; её должен подтвердить специалист по сайту. Перевод SEO-тайтла не заменяет техническую настройку индексации. Также нельзя автоматически считать одинаковыми поисковые запросы в разных странах только потому, что они выражают похожее намерение.

Наконец, назначьте владельца обновлений. После запуска появятся новые товары, изменения условий и сообщения об ошибках. Нужно понимать, как они попадут в другие языки и как будет видна готовность каждой версии. Без такого процесса даже качественная локализация постепенно расходится с основным сайтом. Поддержка начинается с простого правила: изменение исходника должно создавать понятную задачу для всех затронутых версий.

Учебный сценарий: запуск версии интернет-магазина

Представим магазин, который решил перевести каталог и оформить продажи на другом языке. Это условная ситуация для разбора процесса, а не описание проекта бюро. Команда начинает с выгрузки названий и описаний, после чего обнаруживает, что размеры в таблицах хранятся как изображения. Одновременно выясняется, что письма создаёт отдельный модуль и они вообще не попали в первоначальную оценку. Переведённый каталог ещё не образует готовый сервис.

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

Во время пилота обнаруживается длинное название характеристики, которое не помещается в мобильной таблице. Вместо просьбы «сократить всё» команда определяет конкретные узкие поля. Дизайнер меняет поведение таблицы, переводчик предлагает короткие подписи там, где они сохраняют смысл, а маркетолог утверждает названия. Такое решение переносится на весь каталог. Исправление одной системной причины полезнее сотен ручных сокращений в отдельных карточках.

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

Какие решения нельзя оставлять переводчику

Лингвист может заметить, что обещание «доставка завтра» плохо связано с часовыми поясами и географией нового рынка. Но он не вправе самостоятельно заменить его на «доставка за три дня». Это изменение коммерческого условия, для которого нужны данные владельца бизнеса. Вопрос следует зафиксировать и передать ответственному сотруднику. До ответа можно подготовить согласованный временный вариант либо отложить публикацию конкретного блока.

Аналогично нельзя самостоятельно менять условия возврата, гарантии, согласия или названия юридических лиц. Перевод сохраняет содержание исходного документа; адаптация этих условий к рынку представляет собой отдельную работу. Когда она необходима, заказчик должен привлечь подходящего специалиста и затем передать утверждённый текст для локализации. Иначе языковое улучшение способно незаметно создать новое обещание, которое компания не собиралась давать.

Особого внимания требуют надписи, связанные с безопасностью и техническими ограничениями. Сокращение ради кнопки или макета не должно убирать существенное условие. Если места недостаточно, команда меняет структуру: добавляет понятную ссылку, раскрытие или отдельный блок, сохраняя доступность информации в нужный момент. Конкретный вариант выбирают по задаче интерфейса и применимым требованиям, а не по желанию оставить исходную высоту карточки любой ценой.

Как описать найденную ошибку так, чтобы её исправили

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

Также обозначьте последствия. Неверная запятая в информационном абзаце и непонятная кнопка подтверждения заказа требуют разного приоритета. Сначала устраняют проблемы, которые мешают действию или искажают существенный смысл, затем дорабатывают менее критичные детали. Это рабочий способ организовать запуск, а не разрешение навсегда оставить остальные ошибки. Для отложенных замечаний нужны ответственный и понятный срок возвращения к задаче.

Локализация обходится предсказуемее, когда сайт подготовлен к разным языкам до перевода. Проверьте обработку символов, структуру строк, поведение макета, форматы данных, формы, графику и маршрут обновлений. Тогда команда будет тратить время на адаптацию продукта для читателя, а повторные циклы из-за технических ошибок станут заметнее и управляемее.