Мультиязычный корпоративный сайт на Битрикс: карта локализации и порядок работ

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

Задача бизнеса и границы решения

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

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

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

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

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

Две схемы мультиязычного корпоративного сайта: разделы внутри сайта или отдельные сайты

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

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

Схема с отдельными сайтами на одной лицензии даёт больше управляемости. Для каждого сайта можно отдельно настраивать показ даты и валют, анализировать статистику, разграничивать доступ к заказам интернет-магазина. Количество сайтов на разных языках может быть неограниченным для редакций «Бизнес» и выше; для редакций «Первый сайт» и «Старт» количество сайтов ограничено — владельцам этих редакций при необходимости придётся перейти на другую. Минусы — необходимость настройки симлинков и веб-сервера, а также особенности резервного копирования.

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

Карта локализации — главный рабочий документ мультиязычного проекта

Карта локализации — это таблица, которая связывает языковую версию, адрес, тип контента и ответственного. Без неё проект расползается: кто-то перевёл меню, но забыл формы, кто-то обновил русскую страницу, но не тронул английскую. Карта превращает размытое «сделать мультиязычный сайт» в список проверяемых строк.

Что фиксируем по каждой языковой версии

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

Кто заполняет и когда

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

Домены, каталоги и языковые версии: как выбрать схему

Выбор схемы — это компромисс между управляемостью и простотой обслуживания. Ниже — ориентиры для решения.

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

Перевод навигации, меню и технических элементов

Все слова, которые видит посетитель, делятся на две группы: фразы продукта и контент. Фразы продукта — это подписи кнопок, сообщения форм, системные тексты. Контент — то, что наполняет страницы: заголовки, тексты, пункты меню, карточки.

Продукт поставляется на нескольких языках. В русских дистрибутивах присутствуют русский и английский, в немецком — немецкий и английский, в английском — только английский (стандартная поставка). Партнёры добавляют и поддерживают локализации на других языках. Чтобы сайт «заговорил» на одном из имеющихся языков, нужно добавить новый язык и загрузить пакет переводов через систему обновления. Если нужен язык, для которого пакета нет, фразы продукта придётся переводить своими силами.

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

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

Контент: статика, инфоблоки, формы, валюты и региональные настройки

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

Региональные настройки — это набор параметров, которые имеют разные значения в зависимости от культурных особенностей местности. Через них, в частности, задаётся формат показа даты и времени для используемого на сайте языка. Выбор и настройка параметров языка публичного раздела выполняются отдельно для каждого сайта.

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

Учебный пример: карта локализации для условной компании

Учебный пример. Условная компания «Пример» имеет корпоративный сайт на русском и хочет добавить английскую версию для зарубежных партнёров. Заказов через сайт нет, есть формы обратной связи и раздел новостей. Данные условные и не отражают статистику.

Входные условия: - Языки: русский (основной) и английский. - Контент: около двадцати статических страниц, раздел новостей, две формы. - Раздельная статистика и валюты не требуются. - Ответственные: контент-менеджер, переводчик, руководитель проекта.

Действия: 1. На этапе планирования заполняют карту локализации: для английской версии указывают адрес, список страниц, источник новостей, формы и ответственных. 2. Выбирают схему с языковыми разделами внутри одного сайта, так как раздельная статистика и валюты не нужны. 3. Добавляют английский язык и загружают пакет переводов через систему обновления. 4. Создают отдельные типы и файлы меню для английской версии, подключают их в шаблоне. 5. Настраивают компонент новостей на информационный блок с английскими материалами. 6. Переводят статические страницы и размещают их в соответствующем разделе. 7. Проверяют формы: подписи, сообщения об успехе и об ошибке.

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

Ограничение примера: он не описывает интернет-магазин с заказами и валютами — там выбор схемы и объём проверок будут другими. Перед изменениями на рабочем сайте нужны копия, резервирование, тест и план возврата.

Как проверить результат и принять работу

Приёмка опирается на карту локализации и на список требований, согласованный до старта. Проверяют не «красоту перевода», а полноту и работоспособность.

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

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

Типичные ошибки и ограничения

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

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

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ, нужны:

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

С этим набором можно обсуждать схему и порядок работ предметно, а не «на глаз». Работы по структуре и настройке языковых версий выполняются в рамках разработке сайтов на Битрикс, а вопросы доступов и настроек — в рамках администрировании сайта на Битрикс. Резервное копирование при многосайтовой схеме стоит продумать заранее, опираясь на резервном копировании сайта на Битрикс.