Всем привет. В последнее время стал придерживаться модульного построения приложения и возникла необходимость делать их мультиязычными. Про различные Yii:t() я знаю, но это не совсем то, что мне нужно. Объясню на реальном примере. Есть модуль "Блог" и я хочу, чтобы в админе была возможность писать статьи на Русском, Английском и Китайском языках. На данный момент в голове крутятся 3 варианта реализации, но все обладают существенными недостатками. Хотел бы узнать как вы решали подобные задачи.
Условно таблица с статьей имеет поля (которые надо переводить): title | description | text | seo_title | seo_description | seo_keywords
Мои теории сводятся к следующим:
1. Добавлять дубли колонок в ту же саму таблицу с префиксами языков (title_eng, title_zh, ...)
Этот мне не нравится по причине того, что это какой-то ГК и нет возможности гибко добавлять какой-то новый язык. Придется добавлять новые колонки для новых языков
2. Сделать нечто похожее на плагин WP, где в каждую колонку добавляются соответствующие данные, разделенные языковой меткой <:ru> <:en> <:zh> потом это все распарсивается и подставляется в нужные формы. Сложность реализации, возня с парсерами, да и в каждой колонке будет откровенно говоря каша.
3. Сделать дополнительную таблицу blog_article_lang в которой будут все нужные колонки + колонка 'lang' с обозначением языка. По сути получается связь has_many. Мне кажется, что это более менее приемлемый вариант, но опять же возникает усложнение кодовой базы за счет того, что если активировано 3 языка и есть обязательные поля, то статья не добавится пока во всех 3 формах не будут заполнены обязательные поля.
Кто что думает по этому поводу? Как вы решали подобные задачи? Буду рад любому дельному совету
я бы делал три отдельных статьи, для каждого языка свои. Просто выборку этих статей для показа делал исходя из выбранного языка посетителя(уникальный составной ключ например ид языка+слаг, или праймори кей = ид статьи+ид языка). Мудрить с настройкам\колонками и прочим это сущий гемор. Расширить потом до еще 1 языка будет вообще лютый ад.
не очень удачный вариант, на мой взгляд, так как если модуль содержит очень много полей и из них только 5 требуют перевода, то нет смысла создавать избыточные дубли в БД. К тому же нужно убеждаться, что slag во всех статьях (одной серии) одинаков. А это дикие неудобства для того, кто будет наполнять сайт.
Макс: избыточных дублей как раз не будет. Нужна статья на китайском? Пишем на китайском отдельную статью. Проблема слага надуманная. Т.к. Название статьи не меняется почти никогда, т.е. за очень редким исключением. Я бы вручную сделал смену слага. Т.е. это все таки очень важная сео составляющая.
Если выбрать ключом ид статьи+ид языка, то становится вообще просто. Чисто по иду статьи можно подтягивать картинки, еще какие-то данные(в единственном экземпляре). + можно делать уникальный языковой слаг. А в шаблоне выводить урлы языков + каноникал на дефолте. К томуже будет гораздо проще организовать поиск по языковым статьям (настроить сфинкс какойнить). С многоколоночной системой или со связями для языков будут 100% факапы при написании кода. Тем более очень трудно будет расширить или поменять язык в многоколоночной таблице.
Хотя, как вариант: использовать мускул 5.7 и заюзать жсон поля для текстовых данных. Правдо не в курсе как оно там работает т.к. не тестил и не пробовал, но в теории хранить жсон объект с нужными тебе языками вполне себе идея. Правда не понятно как реализовывать поиск по таким таблицам.
Добрый день.
Вот ссылки, первые рассчитаны на yii1, но я переделывал под yii2 и всё работало отлично.
Обходился одной таблицей, где, например, для заголовка были два варианта, английский и русский, title_en and title_ru.
Последняя ссылка - расширение для yii2 раз два три
Расширением не пользовался, ничего не могу сказать. А по первым двум - адаптировал под свои нужды.
Первые 2 ссылки реализуют идею №1. Это не очень хороший вариант, поскольку я заранее не знаю какие языки буду использовать.
Последняя ссылка, как я понял по коду - это реализация идеи №3, которая так же не отменяет тех проблем которые я описал в частности валидации.
Но лично для меня более приемлемым является так же вариант №3. Просто надеюсь, что есть еще какие-то варианты)
Средний
