Возможные подводные камни на многоязычном сайте Drupal? - PullRequest
0 голосов
/ 14 декабря 2009

Я собираюсь отправиться в путешествие по созданию многоязычного сайта на Drupal, где мне, скорее всего, придется довольно активно использовать виды, панели и таксономию. Я немного обеспокоен подходом «новый узел для каждого языка», особенно с использованием панелей.

До сих пор я заставлял его работать аналогично тому, что я хочу, не имея многоязычной поддержки типа контента Panels и выбирая контент, который * Current language and language neutral. Кажется, это работает, как ожидалось, но я вижу некоторые проблемы с этим. Может случиться так, что мне понадобится комиссия по конкретному языку (например, не на английском). Если мне нужно, чтобы все мои панели были мультиязычными, мне кажется, что нужно много работы, чтобы разместить узлы для каждого столбца на каждой странице на каждом языке. Я думаю, что мог бы решить эту проблему, извлекая контент с каким-то видом с аргументами, но это, скорее всего, также приведет к большой работе.

Есть ли какой-то правильный способ сделать то, что я пытаюсь описать, или у меня есть много, казалось бы, ненужной работы?

Ответы [ 2 ]

2 голосов
/ 14 декабря 2009

Я предполагаю, что у вас есть модуль i18n (http://drupal.org/project/i18n) и модуль Views). Затем вы можете создать представление для каждого языка - можно выбрать язык в разделе «Фильтр» определения представления.

Если у вас есть представления, вы можете связать их с меню или блоками. Проблема в том, что у вас должна быть отдельная версия блока или меню для каждого языка с соответствующим представлением - Drupal сам выбирает правильную версию языка в соответствии с конфигурацией (обычно тип содержимого устанавливается в браузере). Я не нашел более простого способа сделать это.

К счастью, подготовка многоязычного контента не так уж и сложна благодаря функции transalte для узлов после включения модуля i18n, поэтому новый узел для каждой страницы - это то, с чем можно жить.

Кстати, вы правы в том, что Drupal делает i18n - не лучшее решение, о котором можно подумать. Иногда мне тяжело с этим.

0 голосов
/ 14 декабря 2009

Ну, есть некоторые серьезные проблемы с взглядами на перевод терминов таксономии или названий слов. Это может быть решено с помощью некоторых дополнительных модулей или / и специального PHP-кода внутри полей представлений. Обычно 70% модулей не поддерживают перевод, тогда вам нужно их патчить для поддержки. В то время как у других есть возможность перевода, но это может быть два возможных способа: использовать таблицу переменных для хранения различных зависимостей пользовательского интерфейса перевода (необходимо переключиться на другой язык, чтобы найти строку) или использовать таблицы полей перевода, чтобы использовать «интерфейс перевода» из меню администратора ,

Пока это все:)

желаю удачи!

...