Если на сайте есть несколько языков, контактная форма должна быть переведена не только визуально, но и технически: подписи полей, текст кнопки, сообщения об ошибках, уведомления на почту и, в идеале, URL языковой версии должны соответствовать языку страницы. Иначе пользователь видит форму на одном языке, а подтверждение или письмо приходит на другом, что сразу режет доверие.
На практике задача решается по-разному. Для небольшого сайта иногда достаточно перевести сам плагин формы и вручную заменить тексты. Для корпоративного сайта или лендинга с несколькими языками лучше строить отдельные языковые версии страниц и переводить форму в составе каждой версии. Если сайт большой, а формы используются в разных шаблонах, важно заранее понять, где хранится текст формы: в настройках плагина, в переводах темы, в строках интерфейса или в содержимом страницы.
Сначала определите, что именно нужно перевести
Под «переводом контактной формы» часто имеют в виду разные вещи, и от этого зависит решение.
- Интерфейс формы — названия полей, плейсхолдеры, кнопка отправки, текст согласия.
- Сообщения формы — ошибки валидации, текст успешной отправки, предупреждения о заполнении обязательных полей.
- Письма — тема и тело уведомления, которое приходит администратору и пользователю.
- Содержимое страницы — заголовок, описание рядом с формой, подсказки, блоки доверия, FAQ.
Если перевести только поля, а письмо оставить на языке исходной версии, получится половинчатое решение. Для сайта услуг это особенно заметно: человек заполняет форму на своём языке и ожидает такой же ответ в письме или на странице благодарности.
Самый надёжный вариант: отдельные языковые версии страниц
Для сайта с двумя и более языками правильнее не пытаться «переключать» один и тот же блок формы на лету, а сделать отдельные языковые версии страницы. Тогда у каждой версии будет свой текст вокруг формы, свои подписи, свои сообщения и, при необходимости, свой шаблон письма.
Такой подход удобен, если:
- у сайта есть полноценная мультиязычность, а не просто перевод нескольких фраз;
- важно SEO-индексирование языковых версий;
- на разных языках отличаются не только текст, но и структура страницы;
- нужно редактировать перевод без вмешательства в код.
Для WordPress это обычно означает использование мультиязычного плагина, который умеет переводить записи, страницы, меню, таксономии и строки интерфейса. Саму форму при этом можно либо дублировать на каждую языковую версию, либо хранить в одном месте, если плагин формы поддерживает перевод строк и сообщений.
Как перевести форму через настройки плагина
Большинство популярных плагинов форм позволяют перевести базовые элементы без кода. Логика у них похожая: вы открываете форму, меняете подписи полей, текст кнопки, сообщения об ошибках и сохраняете отдельную версию для каждого языка или отдельные строки перевода.
Если вы используете плагин формы, сначала проверьте, как он работает с мультиязычностью:
- есть ли у него готовая интеграция с вашим мультиязычным плагином;
- можно ли хранить разные формы для разных языков;
- переводятся ли сообщения об успешной отправке и ошибки;
- поддерживаются ли письма и шаблоны уведомлений.
На практике удобнее всего, когда форма создаётся один раз, а затем переводится через механизм строк или дублируется как отдельная языковая версия. Если плагин хранит тексты в произвольных полях и не отдаёт их в систему перевода, придётся либо использовать другой плагин, либо переводить часть строк вручную через фильтры и шаблоны.
Что проверить в форме после перевода
После настройки откройте каждую языковую версию страницы и проверьте не только видимые подписи, но и поведение формы:
- плейсхолдеры не остались на исходном языке;
- текст кнопки соответствует языку страницы;
- сообщения об ошибке выводятся на нужном языке;
- страница благодарности или уведомление после отправки тоже переведены;
- письмо администратору приходит с корректной темой и текстом.
Если форма отправляется, но письмо приходит не на том языке, проблема обычно не в WordPress как таковом, а в шаблоне уведомления самого плагина формы.
Перевод интерфейса WordPress и перевод содержимого — это не одно и то же
Частая ошибка — считать, что перевод языка сайта автоматически переведёт всё вокруг формы. На деле WordPress переводит только интерфейс ядра, темы и плагинов, если для них есть языковые файлы. Это не затрагивает содержимое страницы и не всегда затрагивает тексты, которые вы сами ввели в конструкторе формы.
Например, если тема уже локализована, админка и системные сообщения будут на нужном языке. Но подписи полей формы, которую вы собрали в плагине, всё равно могут остаться на исходном языке, пока вы не переведёте их отдельно. Поэтому при настройке мультиязычности нужно смотреть на три слоя:
- язык интерфейса WordPress и плагинов;
- язык контента страницы;
- язык самой формы и её сообщений.
Если эти слои смешать, потом сложно понять, где именно сломался перевод.
Когда нужен ручной перевод, а когда можно использовать автоматический
Автоматический перевод полезен как стартовая точка, особенно если у вас много страниц и нужно быстро собрать черновую языковую версию. Но для контактной формы я бы не оставлял машинный перевод без проверки, если от формы зависят заявки, продажи или репутация компании.
Ручная редактура нужна хотя бы для:
- названия полей и подсказок;
- текста согласия на обработку данных;
- сообщений об ошибках;
- письма после отправки;
- страницы благодарности.
Машинный перевод часто ошибается именно в коротких интерфейсных фразах: может сделать текст слишком формальным, неестественным или двусмысленным. Для лендинга услуг это критично, потому что форма — одна из точек конверсии. Если язык выглядит неаккуратно, пользователь может просто не отправить заявку.
Если форма встроена в страницу через конструктор или блоки
На сайтах на Gutenberg, Elementor, WPBakery и похожих конструкторах форма часто находится прямо внутри контента страницы. В этом случае важно понять, как именно хранится её текст.
Есть два типичных сценария:
- Форма как отдельный объект плагина — тогда переводится сама форма, а на страницу вставляется её шорткод или виджет.
- Форма как часть шаблона страницы — тогда переводится не только форма, но и весь блок, где она находится.
Если форма вставлена через шорткод, обычно проще поддерживать отдельные языковые версии страницы и подставлять в них нужную форму. Если же форма собрана прямо в шаблоне конструктора, проверьте, умеет ли ваш мультиязычный плагин переводить такие блоки без потери разметки. На сложных страницах это особенно важно: при неудачном переводе ломаются отступы, кнопки или обязательные поля.
Что делать с письмами и уведомлениями
Переведённая форма без переведённого письма выглядит незавершённо. Администратор получает заявку, но тема письма, служебный текст или подпись могут быть на другом языке. Если на сайте несколько языков, лучше сразу настроить отдельные шаблоны уведомлений для каждой версии.
Проверьте минимум три вещи:
- тему письма;
- текст в теле письма;
- имя отправителя и адрес, если они формируются динамически.
Если плагин формы позволяет использовать переменные, убедитесь, что они подставляются корректно в каждой языковой версии. Иногда проблема не в переводе, а в том, что в шаблоне письма остались старые названия полей или служебные метки.
Как проверить, что перевод формы работает правильно
После настройки не ограничивайтесь визуальной проверкой страницы. Отправьте тестовую заявку с каждой языковой версии и посмотрите, что происходит на всех этапах:
- Открывается нужная языковая версия страницы.
- Форма и подписи отображаются на правильном языке.
- Сообщение об успешной отправке соответствует языку страницы.
- Письмо приходит с корректной темой и текстом.
- Если есть страница благодарности, она тоже переведена.
Если один из пунктов не совпадает, ищите источник текста именно там, где он хранится: в форме, в шаблоне письма, в строках темы или в содержимом страницы. Это быстрее, чем пытаться «перевести WordPress целиком» наугад.
Когда лучше обратиться к разработчику
Без кода можно решить большинство типовых задач, но есть ситуации, когда проще и надёжнее подключить разработчика или поддержку плагина:
- форма генерируется кастомным кодом темы;
- тексты формы зашиты в шаблон и не редактируются из админки;
- нужно перевести динамические сообщения, которые формируются через PHP-фильтры;
- форма работает нестабильно после подключения мультиязычного плагина;
- нужно сохранить сложную логику валидации и отправки писем на нескольких языках.
Это особенно актуально для корпоративных сайтов и проектов с нетиповой архитектурой. Там попытка «доперевести» форму поверх готового решения часто приводит к дублированию логики и ошибкам в отправке заявок.
Если задача сводится к переводу формы на сайте WordPress, правильный путь почти всегда один и тот же: сначала определить, где живут тексты, затем выбрать способ мультиязычности, потом перевести саму форму, письма и страницу вокруг неё, и только после этого проверять SEO и индексацию языковых версий. Такой порядок экономит время и избавляет от ситуации, когда форма вроде бы переведена, но заявки приходят с неправильными сообщениями или на неподходящем языке.