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

Мой опыт

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

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

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

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

Документация — это отдельный мир, чьи инструменты часто происходят из экосистем разработки (техническая документация) или совместной работы (вики); довольно редко эти инструменты предоставляют предпосылки для интернационализации, позволяющей совместную работу. Однако проблема очень похожа на ту, что возникает с веб-сайтом.

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

Почему лишь немногие сайты могут быть переводимыми?

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

Предпосылки интернационализации веб-сайта:

поддерживать письмо справа налево
публиковать содержимое на нескольких языках без необходимости изменять внутренние ссылки
позволять менять язык на любой странице
учитывать заголовок Accept-Language для направления на правильный язык
разрешать любой язык и тип письма в мире

Звучит обширно и внушительно, но несколько стандартов, таких как UTF-8, пара HTML-тегов и инструменты, продумавшие эти потребности, делают это достаточно легко.

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

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

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

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

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

Не обладая глубокой экспертизой в разработке, давайте сравним эти три инструмента:

У Hugo есть страница, посвящённая многоязычной публикации, она полная, содержит примеры, это важно для этого проекта ⇒ пробуйте <3
У Jekyll нет страницы об интернационализации, если только не согласиться использовать плагин и принять связанные с ним ограничения совместимости и «колхозинг» ⇒ бегите!
У Eleventy есть страница об интернационализации, так что это кажется возможным, но очень ручным, это не внушает доверия ⇒ бегите!
Pelican рассматривает только перевод одной статьи, нет отдельной страницы, посвящённой интернационализации, зародыша функциональности недостаточно ⇒ бегите!
У Publii нет страницы об интернационализации ⇒ бегите!

Размышления недолги: хотите статический сайт «под ключ» и работающий на нескольких языках? Используйте Hugo.

Это не личное против Pelican и Jekyll, но помимо того, что у них меньше функций, чем у Hugo, само требование изменять заголовки переводимых файлов — это обременительный шаг в автоматизации. А ведь цель — автоматизировать всё с минимальными усилиями! Некоторым проектам удаётся правильно интернационализировать веб-сайты с помощью этих инструментов, ценой больших усилий и, вероятно, предлагая меньше функций (например, URL-адреса будут на английском, а не переведёнными).

Пример из практики — этот блог

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

Никаких изменений не должно требоваться в статьях на исходном языке
Использование Weblate в качестве платформы перевода
Никакой настройки в Weblate для добавления новой статьи
Никакой настройки в Hugo для добавления языка
Полностью автоматизированная публикация

Выполненные шаги просты.

Найти удовлетворительную организацию контента

content/fr будет содержать весь контент сайта
l10n/ — все файлы переводов
l10n/config — строки для перевода, касающиеся перевода Hugo
l10n/pot — шаблоны переводов (POT-файлы)
l10n/po/%lang% — переводы на каждый язык (PO-файлы)

Конвертер формата po4a будет преобразовывать содержимое в шаблоны переводов (POT-файлы).

Скрипт на Python будет вызывать polib для определения языков, на которых хотя бы одна статья переведена как минимум на 80% (процент переведённых исходных слов).

Другой скрипт на Python будет обновлять конфигурацию Hugo, используя те немногие параметры, которые нужно перевести (название блога, описание блога…).

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

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

Результат и выводы

Наше сообщество свободного программного обеспечения имеет возможность очень легко создавать многоязычные сайты.

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

Поэтому эта статья призвана восполнить этот пробел и побудить заинтересованные проекты копировать этот механизм.

Инструментарий наверняка будет улучшен и упрощён и сохранён в небольшом выделенном проекте, объясняющем его работу для максимального повторного использования. А пока ищите git-репозиторий сайта languages-in-floss, чтобы найти там несколько скриптов.