Terjemahan simpul vs terjemahan entitas (bidang)


26

Saya ingin tahu apa yang Anda rekomendasikan untuk situs multilanguage. Misalnya, pertimbangkan kasus berikut: Halaman dan kontennya harus tersedia dalam 3 bahasa (misalnya Jerman, Inggris, dan Spanyol); situs ini menggunakan satu tipe profil, beberapa tipe konten dan tampilan, taksonomi, referensi taksonomi, referensi simpul, referensi pengguna dan bidang, koleksi bidang, menu, dan sebagainya. Semua informasi ini harus dapat diterjemahkan.

Sejauh yang saya tahu, ada dua cara untuk memperoleh ini: dengan Terjemahan Entitas dan metode "berbasis simpul", atau yang biasa dengan modul Internasionalisasi dan l10n.

Apa yang harus saya pilih? Dalam hal apa dan mengapa saya harus mempertimbangkan metode alih-alih yang lain?

Jawaban:


8

Randy Fay baru-baru ini membuat pos yang membahas kemungkinan yang dicapai dengan Entity Translations, di mana Gabor Hojtsy mengomentari beberapa pertimbangan untuk dipertimbangkan:

Beberapa hal baik yang ditawarkan oleh terjemahan simpul [baik lama] termasuk dukungan untuk komentar simpul yang terpisah (mis. Komentar bahasa Jerman dan Inggris Anda tidak akan dicampur); dukungan untuk revisi per bahasa; alur kerja publikasi (mis. simpul Jerman dapat berada dalam alur kerja revisi pra-publikasi saat bahasa Inggris sudah diterbitkan, tindakan terkoordinasi dapat menerbitkan beberapa versi bahasa ketika semua mencapai langkah tertentu dalam alur kerja, dll); penanganan izin yang berbeda (mis. orang tertentu hanya dapat mengedit terjemahan Jerman bukan asli bahasa Inggris), berkat sistem akses simpul Drupal yang berlebihan, dll. Pikirkan tentang menu. Sebagian besar situs tidak berencana memiliki struktur menu 1-1 untuk semua versi yang diterjemahkan.

Peringatan utama seperti yang saya lihat untuk Terjemahan Konten / Entitas / bidang-tingkat sekarang bermuara pada kasus Drupalisme tua usia itu: judul simpul ... Ini bukan benar-benar bidang, sehingga tidak dapat diterjemahkan tanpa modul lain, dan berpotensi beberapa pekerjaan patch. Sampai sekarang, saya pikir terjemahan lapangan masih sangat "eksperimental", tetapi lebih banyak kekuatan bagi Anda untuk mendorong maju ke wilayah baru.


Terima kasih. Poin yang sangat menarik dan pro untuk node translaion.
Lance


5

Saya menggunakan terjemahan Node tetapi sekarang setelah saya mencoba Terjemahan Entitas , itu pasti salah satu favorit saya!

Saya pikir masalah utama adalah fungsi impor dengan Terjemahan Entitas, karena ada diskusi panjang di komunitas Drupal. Kalau tidak, saya membaca tentang modul baru, tetapi saya belum mencobanya. Tapi saya akan memberikan tanggapan saya setelah itu!

Jika Anda menggabungkan Terjemahan Entitas dengan modul Judul , Anda bisa menerjemahkan semuanya. Saya juga lebih suka modul " Pembaruan pelokalan ".

Jadi, Anda harus menginstal dan mengaktifkan modul yang disumbangkan ini:

Dan Anda harus mengaktifkan modul inti ini:

  • Lokal
  • Terjemahan Konten.

Semoga berhasil!


Ringkasan hebat tentang topik ini, +1!
Pierre.Vriens

2

Saya tahu saya membangkitkan orang mati di sini tetapi:

Dari apa yang dapat saya katakan, metode terjemahan simpul 6-gaya (setiap terjemahan adalah simpul baru) masih merupakan satu-satunya cara yang berguna untuk menerjemahkan konten, memiliki manfaat menjadi apa yang digunakan semua orang dan secara fungsional lengkap. (Judul Node bukan bidang dalam 7, dan karena itu tidak dapat diterjemahkan bidang, di antara kekurangan konyol lainnya.)

Anda akan selalu menggunakan i18n / locale, satu-satunya pilihan (yang sebenarnya bukan pilihan) adalah terjemahan level atau level bidang, yang hanya terjemahan node yang mungkin berguna.

Sunting: Sejak ini ditulis, Terjemahan Entitas + Modul judul telah membuat terjemahan tingkat lapangan sangat efektif. Jika Anda dapat menggunakannya, Anda harus melakukannya.


5
Ini adalah modul contrib, tetapi modul Title ( drupal.org/project/title ) memungkinkan judul node dikonversikan agar berfungsi sebagai bidang.
Patrick Kenny

1

Terjemahan entitas lebih masuk akal dalam banyak kasus daripada terjemahan node; tapi sayangnya itu sebenarnya bukan pilihan yang layak untuk D7 karena banyak modul masih tidak mendukungnya. Orang yang melakukan presentasi dan menunjukkan betapa hebatnya itu hanya melakukan pekerjaan yang sangat sederhana. Misalnya, sesuatu yang umum / sepopuler koleksi lapangan masih belum didukung oleh ET.

Ketika kami memulai situs multibahasa baru, kami selalu memulai dengan ET karena itu adalah ide yang bagus. Kami tetap menggunakannya sampai kami menemukan terlalu banyak masalah dengan hal-hal yang tidak kompatibel .. dan akhirnya kami kembali ke metode D6 yang lama.


Bisakah Anda memberikan detail lebih lanjut tentang kesulitan yang Anda alami? Kami berada dalam situasi yang sama dengan yang Anda jelaskan (membuat situs baru, perlu memutuskan model yang akan kami gunakan untuk terjemahan), dan saya ingin tahu apakah situs kami cukup sederhana sehingga kami tidak akan menemui masalah yang Anda miliki. Mengetahui lebih banyak pengalaman Anda akan sangat membantu.
Josh

Ada lebih dari 6000 modul untuk D7; sulit mengatakan mana yang akan berhasil dan mana yang tidak. Saya tahu koleksi bidang tidak diterjemahkan dengan benar dengan ET. Saya yakin ada yang lain. Taruhan terbaik adalah dengan mencoba setiap bundel saat Anda membuatnya dan melihat apakah itu dapat diterjemahkan menggunakan ET. Anda dapat mencampur ET dan NT di situs yang sama; tetapi tidak dalam bundel yang sama. Itu membuat ET lebih berbahaya seolah-olah Anda akhirnya menambahkan jenis bidang nanti yang sebelumnya belum Anda verifikasi dan tidak didukung; atau Anda menambahkan beberapa fungsi yang tidak didukung; Anda mungkin dalam kesulitan.
liquidcms
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.