Перевод узла против перевода сущности (поля)


26

Я хотел бы знать, что вы, ребята, рекомендуете для мультиязычного сайта. Например, рассмотрим следующий случай: страница и ее содержимое должны быть доступны на 3 языках (например, немецкий, английский и испанский); сайт использует один тип профиля, несколько типов контента и представлений, таксономию, ссылки на таксономию, ссылки на узлы, ссылки на пользователей и поля, коллекции полей, меню и так далее. Вся эта информация должна быть переводимой.

Насколько я знаю, есть два способа получить это: с помощью Entity Translation и метода «на основе узлов», или обычный метод с модулями интернационализации и l10n.

Какой путь мне выбрать? В каком случае и почему я должен рассмотреть метод вместо другого?

Ответы:


8

Рэнди Фэй недавно создал пост, в котором обсуждаются возможности, достигнутые с помощью Entity Translations, где Габор Хойци прокомментировал некоторые соображения, которые следует взвесить:

Некоторые хорошие вещи, предлагаемые переводом [старый добрый] узел, включают поддержку отдельного комментирования узла (например, ваши комментарии на немецком и английском языках не будут смешиваться); поддержка языковых версий; рабочие процессы публикации (например, немецкий узел может находиться в рабочем процессе редакции перед публикацией, в то время как английский уже опубликован, скоординированные действия могут публиковать версии на нескольких языках, когда все достигают определенного шага в рабочем процессе и т. д.); различная обработка разрешений (например, некоторые люди могут редактировать только немецкие переводы, а не английские оригиналы), благодаря чрезмерной системе доступа к узлам в Drupal и т. д. Подумайте о меню. Большинство сайтов не планируют иметь 1-1 структуры меню для всех переведенных версий.

Главное предостережение, которое я вижу в переводе контента / сущности / уровня поля, сейчас сводится к тому давнему особому случаю Drupalism: заголовок узла ... На самом деле это не поле, поэтому его нельзя перевести без другого модуля и, возможно, какой-то патч работает. На данный момент, я думаю, что полевой перевод все еще очень «экспериментальный» фундамент, но он дает вам больше возможностей для продвижения на новую территорию.


Спасибо. Очень интересные точки и преимущества для трансляции узлов.
Ланс

5

Сюзанна Кеннеди и Флориан Лоретан в презентации на DrupalCon Denver обратились к этому вопросу. Кажется, что перевод сущностей - это путь в будущее, и он, по крайней мере, частично предназначен для интеграции в ядро.

Их рекомендация состояла в том, чтобы использовать перевод сущностей, если вам не нужна поддержка для пересмотра.


2
Действительно, Entity Translation теперь является частью Drupal 8 Core. Согласно странице проекта .
Танус

5

Я использовал перевод Node, но теперь, после того как я попробовал Entity Translation , он определенно мой любимый!

Я думаю, что основной проблемой является функция импорта с Entity Translation, потому что в сообществе Drupal существует долгая дискуссия. В противном случае я читал о новом модуле, но я еще не пробовал. Но я дам вам свой отзыв позже!

Если вы объедините Entity Translation с модулем Title , вы сможете перевести все. Я также предпочитаю модуль « Обновление локализации ».

Таким образом, вы должны установить и включить эти дополнительные модули:

И вы должны включить эти основные модули:

  • Locale.
  • Перевод контента.

Удачи!


Отличное резюме по этой теме, +1!
Pierre.Vriens

2

Я знаю, что здесь воскрешаю мертвых, но:

Из того, что я могу сказать, метод перевода узла в 6 стилях (каждый перевод является новым узлом) по-прежнему является единственным полезным способом перевода контента, который имеет то преимущество, что все привыкли и функционально завершены. (Названия узлов не являются полями в 7, и, следовательно, не могут быть переведены полем, среди других глупых недостатков.)

Вы всегда будете использовать i18n / locale, единственный выбор (который на самом деле не является выбором) - это перевод на уровне узла или на уровне поля, из которых, вероятно, будет полезен только перевод узла.

Изменить: С тех пор, как это было написано, модуль Entity Translation + Title сделал перевод на уровне поля очень эффективным. Если вы можете использовать их, вы должны.


5
Это модуль contrib, но модуль Title ( drupal.org/project/title ) позволяет преобразовывать заголовки узлов в функции полей.
Патрик Кенни

1

Трансляция сущностей в большинстве случаев имеет гораздо больший смысл, чем трансляция узлов; но, к сожалению, это не совсем приемлемый вариант для D7, так как многие модули все еще не поддерживают его. Люди, которые делают презентации и показывают, как это просто замечательно, делают очень простую работу. Например, что-то такое же общее / популярное, как коллекции полей, все еще не поддерживается ET.

Когда мы начинаем новый многоязычный сайт, мы всегда начинаем с ET, так как это отличная идея. Мы придерживаемся этого до тех пор, пока не обнаружим слишком много проблем с несовместимыми элементами ... и затем в конечном итоге переключимся на старый метод D6.


Не могли бы вы рассказать подробнее о трудностях, с которыми вы столкнулись? Мы находимся в той же ситуации, что вы описали (создание нового сайта, нужно выбрать модель, которую мы будем использовать для перевода), и мне интересно, если наш сайт достаточно прост, мы не столкнемся с проблемами, которые у вас есть. Знание большего количества деталей вашего опыта было бы чрезвычайно полезно.
Джош

Есть более 6000 модулей для D7; Трудно сказать, какие из них будут работать, а какие нет. Я знаю, что полевые коллекции не переводятся должным образом с ET. Я уверен, что есть другие. Лучше всего попробовать каждый пакет при его создании и посмотреть, можно ли его перевести с помощью ET. Вы можете смешивать ET и NT на одном сайте; но не в одном пакете. Это делает ET более опасным, как если бы вы в конечном итоге добавили тип поля, который вы ранее не проверяли и который не поддерживается; или вы добавляете некоторые функции, которые не поддерживаются; Вы можете быть в беде.
liquidcms
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.