Linguarius.

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

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

Содержимое посадочных страниц лежит в JSON: для двуязычных страниц русская и английская версии находятся рядом в одной модели. Цены, описания услуг и ответы на вопросы вынесены в отдельные общие файлы. Статьи базы знаний остаются в Markdown. Такое устройство позволяет редактировать материалы через Pages CMS и при этом сохранять контроль над тем, какой HTML получится после сборки.

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

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

Проверять нужно и связи между страницами

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

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

Где заканчивается статическая страница

Eleventy отдаёт готовый HTML, но заявка с приложенным документом требует серверной обработки. Форма отправляет имя, контакт, описание задачи и файлы в PHP-обработчик. Он проверяет поля и типы вложений, после чего отправляет письмо по SMTP. База данных для заявок не нужна: файл проходит через обработчик и не остаётся в хранилище сайта.

Похожую границу я провёл для оплаты. Браузер передаёт номер заказа, адрес для чека и сумму серверному обработчику; тот создаёт платёжную ссылку через API Точки. Ключи и настройки платежа остаются на сервере, а на страницу возвращается только ссылка для перехода. Статический сайт отвечает за понятный сценарий, PHP — за операции, которым нужны секреты и проверка входных данных.

В Docker сборка Eleventy выполняется на этапе Node.js, а готовые файлы вместе с PHP-обработчиками обслуживает Apache. У этого разделения есть практическое ограничение: локальный просмотр через Eleventy показывает интерфейс, но не проверяет отправку письма или создание платёжной ссылки. Такие сценарии я проверяю в контейнере и отдельно от проверки контента.

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