Инфраструктура

Мультиязычный сайт на CMS Ghost: как разделить дизайн, переводы и оперативные данные

Мультиязычный сайт на CMS Ghost: как разделить дизайн, переводы и оперативные данные

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

На первый взгляд это тривиальная задача — почти любая CMS поддерживает мультиязычность «из коробки». Но на практике готовые решения почти всегда заставляют выбирать между двумя крайностями.

Проблема: гибкость против надёжности

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

Вторая крайность — зашить всё в код и в шаблоны страниц. Так дизайн защищён на 100%, но любое изменение текста, телефона в шапке или времени работы офиса требует участия разработчика и деплоя. Для контента, который меняется раз в квартал, это ещё терпимо. Для контента, который меняется еженедельно — уже нет.

Мультиязычность усложняет обе крайности вдвое: в первом случае нужно синхронизировать структуру между языковыми версиями вручную, во втором — на каждое изменение уходит время разработчика на каждый язык отдельно.

Подход: три слоя вместо одного

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

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

Слой переводимого контента. Статьи, описания услуг, тексты страниц — стандартный редактируемый контент. Для каждого языка заводится своя версия с собственным человекочитаемым адресом страницы (URL), построенным из заголовка именно на этом языке, а не транслитерированным с оригинала — это важно и для восприятия читателем, и для того, как страницу видят поисковые системы. Версии на разных языках связаны между собой служебной меткой, так что при необходимости система всегда «знает», какая страница на русском соответствует какой странице на английском, и наоборот. Правки в этом слое делает контент-менеджер, без участия разработчика, но каждая языковая версия — это по-прежнему явно управляемая единица.

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

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

Что это даёт на практике

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

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

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

Читать далее

Рассылка в Битрикс24 с учётом часовых поясов

Рассылка в Битрикс24 с учётом часовых поясов

Статья

Как мы научили бизнес-процесс облачного Битрикс24 отправлять тысячу писем так, чтобы каждый клиент получил своё в рабочее время по своему часовому поясу, не в выходной и не одновременно со всеми.

Читать
Не все письма сразу: 7 способов распределить рассылку в Битрикс24 по времени и ящикам

Не все письма сразу: 7 способов распределить рассылку в Битрикс24 по времени и ящикам

Статья

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

Читать
Как собрать вебхук внутри бизнес-процесса Битрикс24 без внешнего сервера

Как собрать вебхук внутри бизнес-процесса Битрикс24 без внешнего сервера

Статья

Связать два портала Битрикс24 можно без отдельного сервера: бизнес-процесс сам отправляет REST-запросы, получает ответы и обновляет карточки. Разбираем, как собрать такой вебхук, почему внутри batch значения кодируются дважды и где всё ломается.

Читать