Комментарии 4
Я может не совсем понял, но что мешало просто использовать i18n и не городить это хрен-пойми что? Нет переводов по умолчанию? Ну так ловить непереведенные фразы в нужной локали и сохранять в БД, где можно и хранить переводы, а не в файлах…
Какая то поделка из серии лишь бы было, точнее пример того, как делать ненадо. Кто плюсует? Объясните свою позицию…
Какая то поделка из серии лишь бы было, точнее пример того, как делать ненадо. Кто плюсует? Объясните свою позицию…
Вы видимо не совсем поняли суть данного решения. Это не переводы интерфейса, как предусматривает механизм i18n, и не переводы фреймворка. Это механизм хранения мультиязычного контента (это может быть и содержимое динамических страниц, мета-данные для SEO итд.). К тому же, тут показан рабочий вариант виджета по управлению деревом с поддержкой мультиязычности (я, к сожалению, не нашёл такого, когда столкнулся с подобной задачей). Если у Вас есть предложения или готовые решения по способу организации мультиязычного контента в Yii2 — можете поделиться. Как говориться, «критикуешь — предлагай».
Отличный рецепт) Только вот интересно, почему не Nested Sets предпочли?) Для хранения меню самое то)
По моим наблюдениям, модель Adjacency List для хранения деревьев в MySQL является более распространённой и понятной (гораздо проще понять связку id -> parent_id, чем вычислять поля left, right, level, особенно при ручном редактировании, в случае сбоя, потери узла, выгрузки в Excel итд.). Скажем так, это дело вкуса, везде есть свои плюсы и минусы Использование конкретной модели дерева не играет особой роли в примере данной статьи. Подобное мультиязычное меню можно также легко сделать и для Nested Sets. Кстати, есть хорошее дополнение для Yii2, которое позволяет менять или комбинировать модели хранения дерева в базе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мультиязычные деревья в Yii2 на примере создания модуля меню