Многоязычный (солярный) WordPress
Почему солярный? Дело в том что пару месяцев назад я написал заметку про WordPress нуарный, где описывал свои горести в создании сайта с несколькими языковыми версиями. И действительно — тогда все выглядело очень мрачно, я решил не использовать плагинов, предназначенных для создания многоязычности, и дальше мыкался в нескольких оставшихся у меня некрасивых вариантах.
Я был в тот момент уверен что любой из серьезных плагинов-переводчиков при слове Woocommerce сразу становится платным (для Polylang это именно так и есть, а WPML платный вообще от природы). В то же время проект был небольшой и ресурса по бюджету не имеющий. Вот я и выкручивался, пока не закрутился окончательно.
А правильный ответ, оказывается, был совсем рядом.
Существует плагин под названием Translatepress, который в своей бесплатной версии позволяет работать с Woocommerce, а также с конструкторами страниц вроде Gutenberg и Elementor. Он, разумеется, в бесплатной версии тоже обрезан, но в несколько другом — не умеет работать более чем с двумя языками (и еще там кое-что, но тут уж читайте сами).
Второй важный момент относительно этого плагина — он использует другой, на мой взгляд гораздо более правильный способ перевода страниц. Я сейчас не про автоматический переводчик, хотя эта опция тоже имеется. Я имею в виду процесс перевода сайта руками (чтоб быть уверенным в результате).
В Polylang для каждой страницы на основном языке создается набор копий, которых нужно заполнить контентом на каждом из альтернативных языков. Это звучит вроде бы совсем неплохо и логично, но представьте сколько работы придется сделать если необходимо изменить структуру уже переведенной страницы. Вам предстоит в n раз больше работы, причем работы кропотливой — повторить изменения для каждой языковой страницы, добавить если нужно перевод.
В Translatepress принцип другой — здесь перевод осуществляется визуально, а единицей перевода являются не страницы, а текстовые элементы внутри этих страниц. То есть страницы не размножаются, структура для исправления одна, править их проще — сразу виден результат.
За это, конечно, есть и своя плата — как раз в случае если у нас есть целиком переведенные страницы (скажем, статья, полученная из агентства переводов), то это делает необходимым усложнение структуры страницы, поскольку она должна содержать все возможные переводы, разбитые особыми шорткодами (вот здесь о них подробно).
Вторая потенциальная проблема — такой сайт может работать чуть медленнее за счет увеличившегося «веса» страниц. Впрочем, в современных сайтах основной объем страницы приходится вовсе не на текстовые фрагменты, а скорее на циклопические вставки javascript и неоптимизированные картинки, так что падение эффективности должно быть ничтожным.
Какие из всего этого выводы?
1. Если говорить именно о плагинах и темах: cмотреть не только на пару лидеров, но еще и на резвых претендентов, которые еще не зажрались и могут предложить более интересные условия.
2. Если существуют действительно критические точки в проекте — они не могут и не должны быть выстроены с помощью бесплатных ресурсов. То есть если языков перевода сайта три — все, нужно покупать плагин с поддержкой, а не мудрить с бесплатными.
3. Не бояться задавать вопросы — куча народу в буквальном смысле шла пешком по тем же самым граблям.