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

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

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

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

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

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

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

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

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

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

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

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

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

• Перевод сущностей .
• Название .
• Обновление локализации .

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

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

Удачи!

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

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

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

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

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

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