Переклад вузла проти суб'єкта (поля)

Мені хотілося б знати, що ви рекомендуєте для багатомовного сайту. Наприклад, розглянемо такий випадок: сторінка та її вміст мають бути доступними трьома мовами (наприклад, німецькою, англійською та іспанською мовами); на сайті використовується один тип профілю, кілька типів вмісту та поглядів, систематика, систематика-посилання, посилання на вузли, посилання користувачів і польових посилань, колекції полей, меню тощо. Вся ця інформація повинна бути перекладною.

Наскільки мені відомо, є два способи отримати це: за допомогою перекладу Entity і методу, заснованого на вузлах, або звичайного з модулями інтернаціоналізації та l10n.

Який шлях вибрати? У якому випадку і чому я повинен розглянути метод замість іншого?

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

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

Найважливіший застереження, як я вважаю, що це переклад вмісту / сутності / перекладу на рівні прямо зараз, зводиться до особливого випадку друпалізму, який є віком: назва вузла ... Це насправді не поле, тому його не можна перекласти без іншого модуля, а потенційно деяка робота з виправленням. На даний момент, я думаю, що переклад на місцях все ще є дуже "експериментальним" підґрунтям, але ви більше сил для того, щоб просуватися на нову територію.

Презентація Сьюзен Кеннеді та Флоріана Лоретана в DrupalCon Denver вирішила це питання. Здається, що переклад сутності - це шлях майбутнього і хоча б частково планується для інтеграції в основну.

Їх рекомендація полягала у використанні перекладу юридичних осіб, якщо вам не потрібна підтримка для перегляду.

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

Я думаю, що головною проблемою є функція імпорту за допомогою Entity Translation, оскільки в спільноті Drupal триває дискусія. Інакше я читав про новий модуль, але ще не пробував. Але я дам вам свої відгуки після цього!

Якщо поєднати Entity Translation з модулем Title , ви можете перекласти все. Я також віддаю перевагу модулю " Оновлення локалізації ".

Тож вам доведеться встановити та включити ці модулі, що надаються:

• Суб'єктний переклад .
• Назва .
• Оновлення локалізації .

І вам потрібно ввімкнути ці основні модулі:

• Місцевий пошук.
• Переклад вмісту.

Щасти!

Я знаю, що тут я піднімаю мертвих, але:

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

Ви завжди будете використовувати i18n / locale, єдиний вибір (який насправді не є вибором) - це переклад на рівні вузла або на рівні поля, з яких може бути корисним лише переклад вузла.

Редагувати: Оскільки це було написано, модуль перекладу особи + заголовок зробив переклад на рівні поля дуже ефективним. Якщо ви можете їх використовувати, вам слід.

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

Коли ми запускаємо новий багатомовний сайт, ми завжди починаємо з ET, оскільки це чудова ідея. Ми дотримуємося цього, доки не знайдемо занадто багато проблем із речами, не сумісними .., а згодом перейдемо до старого методу D6.