Ru / Eng на сайте. Как лучше сделать?

Там можно вставлять код плагина в страницу php а не в созданную в контрольной панели?

Рикко: да

Именно в этом проблема. Я не знаю как должна быть создана тема для двух языков.

Рикко: если Вы пишите тему с нуля - пишите ее на основе underscores.me - тема уже готова к мультиязычности. Далее Вам нужно будет скачать POT редактор и сделать языковой файл для второго языка.

Смотрите тут подробнее - WPMAG

Денис Юдин: вроде как проще использовать плагин который позволит разделить сайт на несколько языков.

Рикко: плагин - плагином, а тема должна быть подготовлена к переводу.

Денис Юдин: я использовал чистую с underscores.me. Но разбираться с файлами POT это слишком сложно. Можно ведь обойтись использованием qTranslate-x

Рикко: все от задачи зависит

qTranslate бесплатный, но раньше был жутко глючный

Вы немножко отстали от поезда :) Тот qTranslate который был глючный, давно заброшен. Годами уже. Существует с десяток форков, предложенный Карен Мнацаканян qTranslateX - абсолютно нормален. Подходит ли он по архитектуре - другой вопрос. Но сам плагин в полном порядке.

Игорь Воротнёв: да? ну дай Бог :) Но вообще, меня немного смущает, что плагин не обновлялся больше 1 года и в саппорте висят нерешенные проблемы и вопросы. Вот в те времена, когда он был глючный, все было точно также :)

Игорь Воротнёв: это этот же плагин - WP ?

Денис Юдин: Далеко не всем плагинам необходимо обновление каждую неделю. Это ни о чем не говорит. Вопросы в поддержке в основном либо из-за несовместимости с другими плагинами (что чаще проблема тех плагинов), либо из-за того что люди не почитали доку. Никто не тратит время на пустые ответы идиотам != плагин плохой или заброшен. Это опен-сорс. Основная жизнь плагина тут: https://github.com/qTranslate-Team

Игорь Воротнёв: отлично! я рад, что плагин не умер до конца, мне он в свое время тоже понравился

Игорь Воротнёв: Могу ошибаться, но, помоему, qTranslate X тоже где-то писали, что прекращают поддержку :(.

Денис Янчевский: Да? Тогда сорян за дезу, я такого нигде не встречал, но вполне мог и пропустить эту новость. В таком случае это, конечно же, печально. Для нбеольших сайтов это было очень хорошее и шустрое решение.

Думаю это слишком сложное решение.

Поверьте - вам это не нужно.
Вам нужна надежная система, где без вмешательства в код все работает с ходу, и можно назначить роль переводчика, с отдельным логином - это WPML.

Он очень дорогой. К тому же несмотря на то что qTranslate не поддерживается, появилась новая версия qTranslate-x которая работает.

Рикко: у меня на него пожизненная лицензия, я участвовал в его разработке немного, до версии 3.6, могу помочь, если вам дорого.
qTranslate-X болен той же самой болезнью что изначальный qT - выводит слаги языков как теги, это фундаментально неверно, и кроме того грузит все переводы сразу во фронтенд, то есть переводы все внутри поста, что удваивает и утраивает время загрузки страницы.

ommunist: ну, эт вы конечно сильно загнули по поводу удваивает-утраивает) Да, у архитектуры qTranslate и всех его форков есть недостатки. Впрочем, есть и плюсы. У того же WPML недостатков тоже хватает, и с производительностью там своя кухня. В стоковом виде он тормозит сильнее чем qTranslate. Вы же понимаете, что обычный SELECT в MySQL будет намного быстрее чем SELECT с несколькими JOIN? Даже если этот простой SELECT будет получать удвоенный объем информации в каждой строке выборки, это не снизит его скорость. А вот объединение данных из нескольких таблиц, как это делает WPML - еще как сказывается на производительности. А еще учитывая, что WordPress не использует нативный php-gettext, а использует свой медленный парсер, то микроскопические потери qTranslate вообще не имеют значения. Если говорить именно о скорости работы, то qTranslate - самый быстрый из всех вариантов.

Игорь Воротнёв: в WPML уже все починили в этом смысле.
А откуда дровишки, что WPML не использует native gettext?

ommunist: Починили утечки памяти, сделали пару фич (как автопоиск ID) опциональными (впрочем, через жопу - через opt-out, а не opt-in) но сама архитектура как была, так и осталась. Я с ним годами работаю, у меня десяток сайтов на WPML, среди которых есть очень крупные и с 10+ языков. Неоднократно писались надстройки над WPML как раз для оптимизации его узких мест.

А откуда дровишки, что WPML не использует native gettext?

Я писал не WPML, а WordPress. Впрочем, WPML его тоже не поддерживает. А дровишки отсюда. Тикету больше 6 лет, на минуточку. Если вы еще не сталкивались с таким интересным узким местом, значит еще толком не сталкивались с мультиязычными сайтами на WP :) И я вам даже немножко завидую - у вас еще впереди целая гамма самых интереснейших эмоций по этому поводу )))

ommunist:
>переводы все внутри поста, что удваивает и утраивает время загрузки страницы.
Что за чушь? В каком месте и что оно утраивает?

Есть опыт работы над несколькими проектами WordPress Multisite + мультиязычность. Я вам наоборот скажу, WPML на сетке сайтов, это очень медленно.
Форки qTranslate в этих же условиях работают быстрее.

Игорь Воротнёв: Не, я просто лет 6-7 делаю сайты мультиязычные, в том числе RTL. Сеток сайтов не делал, только на одном домене в основном. В основном на WPML, переключился на него с qT по изложенным причинам. Polylang тогда еще не было.

Тикет интересный, но поскольку я обычно специализированный хостинг под проект беру, проблемы этой не чувствовал никогда. Кстати, там в тикете часов 17 тому запросили конкретику, если она у вас есть, помогите пожалуйста @johnbillion и может его удастся закрыть, раз у вас есть надежные сравнительные данные под рукой.

Дмитрий: а, действительно, в qT-X эта штука уже поправлена.

При прочих равных у меня было такое правило буравчика - если сайт маленький и статический - qT, а если большой и с большими процессами и количеством вовлеченного народу в производство - WPML. Если 2 языка - можно qT, если больше - WPML. Чисто мой опыт, никому не навязываю.

Напоминаю еще раз - есть еще Polylang
(есть еще, но я не касаюсь недопиленных codeforpeople решений и адских xili вещей)