Здравствуйте.
Нужно реализовать перевод представлений типа page. Пункт Field Language:Current user's language не совсем подходит по нескольким причинам:
1. Не переводится title страницы;
2. Есть свои кастомные поля с введенным вручную текстом.
Что я пробовал. Создал представление page с адресом hotels/minsk. Язык по умолчанию русский. Создал другое представление page с адресом en/hotels/minsk с необходимым содержимым на английском языке в надежде, что при переключении языка с русского на английский я перейду на нужную мне страницу. Но в результате при переходе на страницу en/hotels/minsk отображается содержимое русскоязычной страницы с частично переведенным контентом, а не содержимое второго англоязычного представления.
Какие способы разрулить эту ситуацию?
Комментарии
Во вьюсах есть же языковой фильтр.
Данная проблема решается добавлением в Views фильтра Содержимое: Язык (= Язык текущего пользователя), по другому Node translation: Language - Current user's language
При активации фильтра модуль Views отображает ноды в зависимости от текущего языка пользователя.
Само собой после установки модуля Internationalization
Этот вариант не работает, если перевод делается с помощью Entity translation. В данном случае перевод будет с помощью пункта Field Language:Current user's language в разделе Advanced в настройке представления. Но в любом из этих вариантов не решается несколько задач: Перевод заголовков страниц, перевод полей с кастомным текстом.
Частично задачу решил следующим методом.
Установил модуль Views PHP. В разделе PAGE SETTINGS настройки представление в пункте Access появился чекбокс PHP, где можно прописать код и если он возвращает TRUE, то страница отображается.
Прописал я следующий код:
global $language;
$lang = $language->language;
if($lang == en) {
return true;
}
elseif($lang == ru) {
return false;
}
В таком случае нужный функционал достигнут с одним НО: это работает для анонимных юзеров, либо для зарегистрированных, но отличных от админа. В чем здесь может быть загвоздка?
Поля через entity translation всегда переводятся вместе с языком энтити, что удобно и логично и проблем тогда с ними нет, что касается тайтла вьюс у Вас стоит https://drupal.org/project/i18nviews ?
Спасибо, большое. Модуль был установлен, но не дошел, что бы разобраться с ним. Вроде, должен решить мою задачу. Ну и чтобы полностью закрыть вопрос, может подскажите почему выше указанный php сниппет не работает для администратора?
Проверьте настройку мультиязычности в части приоритетов определения языковых предпочтений.
У администратора может стоять язык в профиле с большим приоритетом чем язык из урла.
Менял язык администратора, не сработало. Просто в шаблоне страницы тоже используется такой код, в зависимости от языка загружается тот или иной элемент и это работает для любых ролей.
Поигрался я с Access в представлении и понял, что блок или страница всегда будет видна администратору независимо от установленных здесь настроек: нет доступа или включить доступ другим ролям кроме админ. Соответственно и этот код php для отключения отображения вьюхи не работает. Или нужен какой-то другой код.
...Но по опыту скажу, что это большой геморр, когда идентификатор ноды меняется в зависимости от языковой версии. По этому рекомендую модель entity translation и переводить поля (разумеется переводить можно только необходимые поля). В итоге будет мультиязычная нода/термин с одним идентификатором.
Так я и использую для нод entity translation и в представлениях он тоже используется у меня. Но есть у меня в представлении поле Global: Custom text, где смесь переводимых полей и простого текста. Как это поле переводить? А Заголовок вьюхи как переводить? Ну и верхние и нижние колонтитулы представления, которые тоже Global: Text area?
Возможно и есть другой вариант, кроме как при переключении языка подменять представление другим представлением, но я пока не придумал.
Я стараюсь на мультиязычных сайтах не использовать вьюс )) Точнее использую только для выборки сущностей, а всякий обвес (колонтитулы, заголовки, надписи подписи) делать отдельно: либо внедрять вьюс в ноду, либо в кастомную страницу.
Для простых задач вставить нужный блок вьюс в ноду, в зависимости от языка, не проблема. Но есть случаи, когда нужна страница, а таких страниц у меня много и с разным содержимым и фильтрами, тогда удобнее иметь вьюху типа page.
под "много" вы имеет ввиду одну, но с контекстуальными фильтрами? Или действительно несколько views page ?
Штук 20 без учета фильтров
?♂️