Термины таксономии в заголовке для удобства перевода и скрытый заголовок страницы с точки зрения поисковиков при использовании модуля title.
Здравствуйте! Для экономии времени при переводе однотипных слов на сайте хочу перевести термины таксономии и максимально их использовать при заполнении полей. Таким образом можно будет один раз перевести название поля и термин на нужные языки, и не нужно будет делать перевод для каждого поля. Использую entity translation.
Возникла сложность с заголовком.
1-й способ.
С помощью модуля title делаю его обычным полем. Но поменять тип поля на ссылку на теримн мне не удалось. Как вариант рассматриваю скрыть его и создать другое поле. Скрыть можно прямо через UI при создании поля ... /admin/structure/types/manage/.../fields/title_field(скриншот).
Но возникают два вопроса:
1)Как это будет выглядеть с точки зрения поисковиков.
2)Если я его все же скрою, то нужно ли мне а) лезть в верстку и добавлять тег заголовка к этому полю или б)добавлять через UI в настройках поля /admin/structure/types/manage/.../fields/... (скриншот прилалагаю)
2 способ.
Альтарнативный вариант настроить feeds tamper или написать самописный модуль и задать там правила перевода конкретных слов. Но так как некоторые слова могут быть частью более сложных конструкций и в зависимости от этого переводиться по-разному смотрю больше в сторону первого варианта.
3 способ.
Залезть в настройки поля и в коде поменять тип поля и сделать нужный виджет.
Но боюсь полетят взаимодействия с другими модулями.
4 способ.
Делать автосоздание заголовка из содержимого другого поля с териминами на текущем языке страницы.
(где-то даже была тема, как это делается )
Первый вариант нравится больше всего, и реализовать его проще всего, но большой вопрос в отношении поиcковиков.
Что Вы думаете об этом?
| Вложение | Размер |
|---|---|
 2018-05-04_11-12-44.png | 53.76 КБ |
| 2018-05-04_11-23-51.png | 79.72 КБ |
- Блог
- Войдите или зарегистрируйтесь, чтобы отправлять комментарии
Комментарии
Неизвестно.
Смотрите текущую верстку, если семантически нужно править - правьте, если достаточно обертки предоставляемой fences - используйте ее.
В целом, не понятно что и зачем Вы делаете и как это будет работать. Напишите "живой" пример, очень может быть что Вы не той дорогой идете. Drupal обладает весьма мощной системой переводов, и вероятно есть другие, более подходящие способы решения задачи.
Сейчас очень похоже на попытки забивания гвоздей микроскопом.
Спасибо за ответ.
Конкретные примеры
1)Сайт о музыке.
Сожержимое полей "до, ре, ми" можно сделать с помощью поля типа "ссылка на термин" и заполнить терминами 1- до, 2 - ре, 3- ми.
В целом у меня получается, что в словаре всего 7 терминов. Но в разных полях могут быть сотни их разных сочетаний.
Дальше делаю перевод терминов. При добавлении перевода на другой язык это поле можно будет не переводить, так как туда подставятся переводы терминов. Т.е. не нужно будет делать перевод сотен вариантов сочетаний этих 7 слов. Достаточно один раз перевести 7 слов.
Может есть другие способы чтобы это проще сделать?
Поля - это разные поля (и их прям "много")? Просто, в текущий момент выглядит как не очень хорошее решение.
Наберусь наглости, и попрошу все же еще более детально, прям пример одного материала с разными сочетаниями (не с сотнями, конечно, но с достаточным количеством для понимания структуры модели данных).
А еще, вам не вариант все их назвать ихними международными (латинскими) именованиями - C, D, E, F, G, A, H(B)? Так и не нужно переводить будет...
Спасибо. Не самих полей так много, поле то может быть и одно, но материалов с разными комбинациями в этом поле может быть много, например есть 100 материалов
в материале c nid1 поле заполнено как до, ре, ми
nid2- соль, ми, ля
nid3- ре, фа, соль
И т.д. до nid 100
Спасибо за идею с латинскими буквами, но не подойдет, так как уровень музыкальной грамотности пользователей разный и не все знают латинские обозначения, также есть две классификации, в которых по-разному называют ноты си и си-бемоль в разный странах, и есть еще другие термины кроме нот, знаки альтерации (диезы, бемоли) и др.
Пожтому нужно переводить вручную термины и уже переведенные подставлять.
Ок. Давайте таксономию покорять...
Вам просто нужно добавить поле - ссылку на термин, не переводимое (не включать возможность перевода для поля), и термины будут "подтягиваться" на страницу с нужной локалью.
В настройках отображения материала - выберите нужный формат вывода.
Спасибо. Но задача не отобразить нужный язык в самом поле. Задача - этот термин подтянуть в заголовок или сделать это поле заголовком, но нормальным с точки зрения поисковиков, а в переводе этого материала перевод этого термина подтянуть в перевод заголовка или перевод поля сделать переводом заголовка..
На сколько я понимаю, программным подходом Вы не брезгуете.
Если нужно сделать динамический вывод тайтла, Вам поможет hook_node_view. С его помощью, Вы можете модифицировать любой элемент.
Devel поможет разобраться со структурой имеющихся данных, а если возникнут вопросы по кодовой базе - спрашивайте, с примерами.
Успехов!
Спасибо. Это уже универсальное решение, у меня с хуками пока сложнее, еще нужно разбираться в этом.
Просто подстановка в шаблон проще, чем работа с хуками.
В моем случае я могу точно сказатьЮ динамический это вывод или нет, динамичный он только в момент создания ноды, но это одноразовая подстановка, в принципе title может не меняться уже после создания страницы и страницы могут быть статичными.
Сейчас тестирую с помощью auto_nodetitle и token.
Использую токен [node:field_taxonomy_tags_field_name], где field_taxonomy_tags_field_name - машинное имя поля для терминов.
Было две проблемы
1)первая была с выводом переводов терминов в само поле, описана выше
2)Заголовок создаетс с auto_nodetitle при создании материала и при включении другого языка не пересоздается. Т.е. поле термина берет нужный перевод но при этом не меняет заголовок.
Можно ли как-то это изменить добавив еще какой-то токен? Например какую-нибудь переменную?
Или все же вписать php код.
Если ориентироваться на этот как исходный, но поменять класс и дату на термин
<?php if ($page == 0) { ?>
<Н2 class="title">"><?php print $title?> <?php print format_date($node->created, 'custom', 'd.m.Y') ?>
<?php }; ?>
Смотрю сейчас код Bartik который сейчас у меня включен, у меня заголовок является полем с помощью title и если я правильно понимаю один и тот же класс для заголовков разных типов материалов.
Тип 1 Название1
Тип 2 Название2
Тогда получается нужно либо в шаблоне для этого типа материала либо на странице редактирования поля добавить варианты в раздел Wrapper markup.
Где редактируется список тегов для добавления в этот раздел?
Или можно как-то поменять алгоритм работы модуля, чтобы заголовок создавался не только для языка оригинала но и для каждого языка? Может там просто в модуль надо добавить t или что-то типа того?
Или все же придется в таком случае от автозаполнения заголовка отказываться и делать поле термина заголовком.
с самими терминами, термин создавался, перевод его был в словаре, но в поле перевод не выводился. Причем в заголовок перевод термина подставлялся, а в само поле нет.
С entity translation возникла сложность с выводом переводов терминов в само поле.
перевод добавлялся но в поле было English translation unavailable for term ...
Причем при создании термина на лету при создании материала из поля автозавершения вклдака переводов вообще не появлялась на странцие редактирования термина. При создании термина заранее получалось его перевести.
Было предположение, что это настройки определния и выбора языка или конфликт между модулями entity translation, Content translation, Internalization. Включение только Entity translation, либо разных комбинаций и настроек выбора языка и блока не помогало. На другом сайте были включены все эти модули и их подмодули, но настроен вывод через Entity translation и получилось хотя бы нормально вывести нужный перевод термина в непереводимое поле, как Вы и писали выше. Почему на одном сайте получилось на другом нет, пока не удалось выяснить.
уточнение относительно мощной системы переводов Друпал, цель - минимизировать ручной перевод, а не добавить функцию работы с переводами еще какую-то помимо имеющихся у Друпал.
Например, в Друпале можно делать переводимыми строки, и есть разного рода контриб для работы с переменными (которые можно переводить) из админки.
Спасибо. Variable у меня включен. Уточнение: мне нужно не сам перевод терминов настроить, а подставлять уже переведенные вручную термины в поле заголовка. Если это можно без правки шаблона сделать, а с помощью variable api или другого модуля через UI, то какой путь url к странице внесения этих настроек (/admin ....)?
Сорри, я так и не понял какой результат ожидается, и тем более как относится к поисковикам...
Я на этапе создания нужного мне типа материала уже продумываю, как это будет переведено. Вот схематичный пример материала для демонстрации https://yadi.sk/i/bGCOua613VKmqc Ожидается что у меня в материале есть поле заголовок и поле, например, "нота", поле "нота" заполняется с помощью термина вручную, поле заголовок заполняется с помощью содержимого из поля "нота" (или как предполагалось в одном из вариантов поле "нота" делается заголовком, а стандартное поле заголовка скрывается). Потом я переведу термин "до" на "do", и при создании перевода материала, заголовок будет автоматичсеки перведен за счет того, что термин уже переведен.
Гляньте вот эту статью: https://drupalspb.org/articles/kalabro/bystraya-forma-nastroek-s-variabl...
Возможно там будет часть решения.
Если с тчоки зрения поисковиков неизвестно как будет выглядет скрытый заголовок, то лучши вариант наверное лезть в шаблон или делать как здесь, только вместо даты брать содержимое поля
https://drupal.ru/node/8062
В примере с датой было:
<?php if ($page == 0) { ?>
<Н2 class="title">"><?php print $title?> <?php print format_date($node->created, 'custom', 'd.m.Y') ?>
<?php }; ?>
Но как праивльно указать тогда класс, чтобы это было только для заголовков в этом типе материала?
и как заменить часть про дату (эту если я праивльно понимаю <?php print format_date($node->created, 'custom', 'd.m.Y') на содержимое поля с терминами, предположим машинное имя типа материала "123", а машинное имя поля "abc")
Только пример 10тилетний и про 5й Drupal.
Если спустя 10 лет можно это сделать через UI, то я с удовльствием, но пока только один способ через UI я вижу: скрыть заголовок и обернуть поле тегом заголовка, но вопрос по поисковикам. Как делать с Variable через UI не пойму пока, на какой странице и найти не могу. А способ с добавлением в шаблон относительно простой вроде, технически вставить две строчки в шаблон не сложно, или у этого способа есть какие-то минусы? Вопрос по этому способу, как класс сузить до одного типа материала и как правильно указать, что подставлять.
Вот еще кстати модуль https://www.drupal.org/project/exclude_node_title
58 тысяч сайтов его используют на сегодняшний день, что немало. Если модуль убирает тег заголовка из заголовка, а я потом своему полю этот тег добавлю, то все должно быть нормально для поисковиков, я боюсь если буду смотреть через fire bug то могу пропустить какой-то важный момент, если кто-то этот модуль себе ставил, то что у Вас в firebug на страницах, где он используется? Что с тегами? Как все смотрится по-Вашему для поисковиков?
C помощью views можно легко сделать и заголовок и хлебные крошки.
И заголовок, и хлебные крошки
, и даже небо, и даже Аhttps://www.drupal.org/node/533448 - сравнение относительно популярных модулей для управления хлебными крошками.
Дополнительно - можно написать для данных страниц свои хлебные крошки в своём модуле.
Дополнительно - можно с помощью альтеров и такой-то матери поменять ядрённые хлебные крошки.
А можно наконец-то и объяснить, как на сайте с панелями, сделать хлебные крошки вьюсами.
Спасибо за ссылку на сравнение.
При использовании вараинта с exclude node title и добавлением тега с помощью wrapper тег h1 появлялся у поля с термином, но в крошках и инфомрационном сообщении о создании ноды все же был исходный заголовок.
Код крошек
<div class="breadcrumb"><a href="/ru">Главная</a> » Заголовок, который должен быть заменен 070520184</div>
код поля с термином
Термин который должен стать заголовком excl 07054 ру </h1>
При использовании easy breadcrumbs и crumbs такая же ситуация при первых наиболее очевидных настройках. Возможно если покапаться, можно и с этими модулями настроить крошки для этого способа вывода термина в заголовок. Но пока самым рабочим и быстрым оказалось только октлючение крошки последней страницы вообще, чтобы не высвечивался старый заголовок (на страницах /admin/config/user-interface/easy-breadcrumb и /admin/structure/crumbs соответсвенно ) . Но то, что хлебные крошки демонстрируют все же не полноценную, а частичную замену заголовку, вызывает сомнения о правильности метода в целом с точки зрения посковых систем? есть вероятность, что и поисковики все же будут видеть старый заголовок.
Спасибо за идею. Сложно будет в моем случае порядок организовать нужный терминов. Т.е. нужно, чтобы были определенные термины в определенном порядке и сортировкой это сделат невозможно или очень сложные будут алгоритмы, нужно вручную делать. И если у меня совсем не будет этих ноды статичных, а будут только термины и представления, то получается страницы совсем не проиндексируются, так как представленяи будут заркыты?, если я правильно понимаю. Или я не совсем пойму, что Вы имеет ввиду. Вы можеет описать немного подробнее или прислать ссылку на пример с описанием?
"определенные термины в определенном порядке" откуда этот порядок берется? Сверху вниз по дереву? Или как-то по забористее?
Вам про крошки рассказать? делаем вьюхи с конеткстными фильтрами по TID и NID. Подтягиваем нужные поля. Из вьюх формируем маленькие блоки, которые ставим в специальнный регион. Крошку "Главная" делаем просто текстовым блоком.
УЖС!
А что такое УЖС? Ужас? Почему?
Спасибо. Да, позабористее, не по дереву вниз, очень неудобно будет создавать автоматические сортировки в данном случае,придется много условий делать и сами словари с разным порядком терминов, намного проще вручную вбить. Про крошки, когда до этого этапа дойдет изучу этот способ, спасибо.
А панелями не все пользуются. Как и Display Suite, Context и т.д.
Обновление информации для сочетания auto_nodetitle и token
Заголовок после автоподстановки имеет следующий код при просмотре кода через хром по нажатию правой кнопки мыши:
Термин для подстановки в заголовок 07051 ру
В исходном заголовке был текст 07052018, чтобы по нему потом в коде найти старый скрытый заголовок ctrl+f.
При просмотре кода через браузер не удалось найти такого текста на странице. Т.е. получается что совсем вырезан старый заголовок из кода?
Где то еще он мог остаться? Значит ли это что и посковики будут тогда видеть новый заголовок как нормальный h1?
сам термин при этом - скриншот https://yadi.sk/i/RNP3XM4p3VU5am
По вырезанию exclude_node_title тоже кое-что удалось попробовать, но по нему отдельная тема https://drupal.ru/node/136903
Еще раз код заголовка после автоподстановки, не проставился тег нужный выше
<div class="field-label">Tags: </div>
Возможно лучше тогда использовать модуль метатег как предлагают в этой теме
С помощью модуля metatag
на странице например /admin/config/search/metatags/config/node
можно в заголовок добавить токен поля или термина
Тогда есть два варианта
1)Как-то добавлять токен термина
Но тогда как делать так чтобы именно нужный термин посдтавлялся?
2)Добавлять токен для поля
Но вопрос, как узнать токен для кастомного поля?
Есть немного обходной способ:
При включении auto_nodetitle можно смотреть список доступных токенов
Но там для каждого поля два варианта один с _ другой с - после слова field
От чего это зависит?
Например
Brand [node:field-brand] Поле "field_brand".
Brand [node:field_brand] Term reference field.
Или можно создавать токен самостоятельно
Обновление и дополнение:
Еще встретились средства для замены заголовка
1)Metatag (можно в заголовк подставить значение другого поля, являющегося ссылкой на термин, в конфигурации можно подставить токен этого поля)
Также в этом обсуждении похожая ситуация
https://drupal.stackexchange.com/questions/34978/how-to-change-widget-ty...
предлагают
2) http://drupal.org/project/auto_entitylabel
3)добавление кода
$form['title']['#access'] = FALSE;точнее
function your_module_form_alter(&$form, &$form_state, $form_id) {
if($form_id == 'your_node_form'){
$form['title']['#access'] = FALSE;
}
}
?>
4)можно пытаться помнять тип поля заголовка в базе данных
по этому способу с измемнением в базе данных отдельная тема
(этот способ вероятно самый надежный с точки зрения того, что не будет дублироваться тег H1, но нельзя исключить что изменение в одном месте может повлечь какие-то сбои и конфликты соответсвия с другим модулями )