การแปลโหนดเทียบกับการแปลเอนทิตี (ฟิลด์)

ฉันต้องการที่จะรู้ว่าสิ่งที่พวกคุณแนะนำสำหรับเว็บไซต์หลายภาษา ตัวอย่างเช่นพิจารณากรณีต่อไปนี้: หน้าและเนื้อหาควรมี 3 ภาษา (เช่นเยอรมันอังกฤษและสเปน) ไซต์ใช้ประเภทโปรไฟล์หนึ่งประเภทเนื้อหาและมุมมองหลายประเภทอนุกรมวิธานการอ้างอิงอนุกรมวิธานการอ้างอิงโหนดการอ้างอิงผู้ใช้และฟิลด์การรวบรวมฟิลด์ชุดข้อมูลและอื่น ๆ ข้อมูลทั้งหมดนี้ควรแปลได้

เท่าที่ฉันรู้มีสองวิธีในการรับสิ่งนี้: ด้วยEntity Translationและวิธี "node-based" หรือวิธีปกติกับโมดูลInternationalizationและ l10n

ฉันควรเลือกทางใด ในกรณีใดและทำไมฉันจึงควรพิจารณาวิธีการแทนวิธีอื่น

แรนดี้นางฟ้าเพิ่งสร้างโพสต์พูดคุยเป็นไปได้ที่ประสบความสำเร็จกับการแปลของกิจการที่Gabor Hojtsy แสดงความคิดเห็นในบางส่วนของการพิจารณาที่จะชั่งน้ำหนัก:

บางสิ่งที่ดีที่นำเสนอโดยการแปลโหนด [ดีเก่า] รวมถึงการสนับสนุนสำหรับการแสดงความคิดเห็นโหนดแยกต่างหาก (เช่นความคิดเห็นเยอรมันและภาษาอังกฤษของคุณจะไม่ถูกผสม) การสนับสนุนสำหรับการแก้ไขภาษาต่อ; เวิร์กโฟลว์การประกาศ (เช่นโหนดเยอรมันสามารถอยู่ในเวิร์กโฟลว์การแก้ไขก่อนตีพิมพ์ในขณะที่ภาษาอังกฤษได้รับการเผยแพร่แล้วการดำเนินการประสานงานสามารถเผยแพร่หลายภาษาได้เมื่อทุกขั้นตอนในเวิร์กโฟลว์ ฯลฯ ); การจัดการการอนุญาตที่แตกต่างกัน (เช่นบางคนสามารถแก้ไขการแปลภาษาเยอรมันไม่ใช่ต้นฉบับภาษาอังกฤษเท่านั้น) ต้องขอบคุณระบบการเข้าถึงโหนดที่มากเกินไปของ Drupal และอื่น ๆ ลองคิดถึงเมนู เว็บไซต์ส่วนใหญ่ไม่ได้วางแผนที่จะมีโครงสร้างเมนู 1-1 สำหรับทุกเวอร์ชันที่แปล

ข้อแม้ที่สำคัญที่ฉันเห็นสำหรับการแปลเนื้อหา / นิติบุคคล / ระดับเขตข้อมูลในขณะนี้ลดลงจนถึงอายุพิเศษ Drupalism กรณีพิเศษ: ชื่อโหนด ... มันไม่ได้เป็นเขตจึงไม่สามารถแปลได้โดยไม่ต้องโมดูลอื่นและอาจ แพทช์บางงาน ณ ตอนนี้ฉันคิดว่าการแปลภาคสนามยังคงเป็นเรื่อง "ทดลอง" เป็นอย่างมาก แต่มีอำนาจมากขึ้นสำหรับคุณในการผลักดันไปสู่ดินแดนใหม่

Suzanne Kennedy และการนำเสนอ Florian Loretanที่ DrupalCon Denver ตอบคำถามนี้ ดูเหมือนว่าการแปลเอนทิตีเป็นหนทางแห่งอนาคตและมีส่วนกำหนดไว้อย่างน้อยบางส่วนสำหรับการรวมเข้ากับแกนหลัก

คำแนะนำของพวกเขาคือการใช้การแปลเอนทิตี้เว้นแต่คุณต้องการการสนับสนุนสำหรับการแก้ไข

ฉันใช้การแปลโหนด แต่ตอนนี้หลังจากฉันลองแล้ว แปล Entityมันเป็นสิ่งที่ฉันโปรดปรานที่สุด!

ฉันคิดว่าปัญหาหลักคือฟังก์ชั่นการนำเข้าที่มีการแปลเอนทิตีเนื่องจากมีการอภิปรายกันอย่างยาวนานในชุมชน Drupal มิฉะนั้นฉันอ่านเกี่ยวกับโมดูลใหม่ แต่ฉันยังไม่ได้ลองเลย แต่ฉันจะให้ข้อเสนอแนะของฉันในภายหลัง!

หากคุณรวมการแปลเอนทิตีกับโมดูลหัวเรื่องคุณสามารถแปลทุกอย่างได้ ฉันยังชอบโมดูล "การอัปเดตการแปล " ด้วย

ดังนั้นคุณต้องติดตั้งและเปิดใช้งานโมดูลที่สนับสนุนเหล่านี้:

• การแปลเอนทิตีแปล
• หัวข้อชื่อเรื่อง
• อัปเดตรองรับหลายภาษา

และคุณต้องเปิดใช้งานโมดูลหลักเหล่านี้:

• สถานที่เกิดเหตุ
• การแปลเนื้อหา

โชคดี!

ฉันรู้ว่าฉันเลี้ยงคนตายที่นี่ แต่:

จากสิ่งที่ฉันสามารถบอกได้ว่าวิธีการแปลโหนดแบบ 6 สไตล์ (การแปลแต่ละครั้งเป็นโหนดใหม่) ยังคงเป็นวิธีเดียวที่มีประโยชน์ในการแปลเนื้อหาโดยมีประโยชน์ในการเป็นสิ่งที่ทุกคนคุ้นเคยและเสร็จสมบูรณ์ตามหน้าที่ (ชื่อโหนดไม่ใช่ฟิลด์ใน 7 และดังนั้นจึงไม่สามารถแปลฟิลด์ในหมู่ข้อบกพร่องโง่ ๆ )

คุณมักจะใช้ i18n / locale ตัวเลือกเดียว (ซึ่งไม่ใช่ตัวเลือกจริง ๆ ) คือระดับโหนดหรือการแปลระดับฟิลด์ซึ่งการแปลโหนดเท่านั้นที่มีประโยชน์

แก้ไข: เนื่องจากสิ่งนี้ถูกเขียนโมดูลการแปลเอนทิตี + ชื่อเรื่องทำให้การแปลระดับฟิลด์มีประสิทธิภาพมาก หากคุณสามารถใช้พวกเขาคุณควร

การแปลเอนทิตีทำให้เข้าใจได้ดีกว่าในกรณีส่วนใหญ่กว่าการแปลโหนด แต่น่าเสียดายที่มันไม่ได้เป็นตัวเลือกที่ใช้งานได้สำหรับ D7 เนื่องจากโมดูลจำนวนมากยังไม่รองรับ คนที่ทำงานนำเสนอและแสดงว่ามันยอดเยี่ยมเพียงแค่ทำงานง่าย ๆ เท่านั้น ตัวอย่างเช่นบางสิ่งที่พบได้ทั่วไป / เป็นที่นิยมเช่นการรวบรวมฟิลด์ยังไม่ได้รับการสนับสนุนจาก ET

เมื่อเราเริ่มเว็บไซต์พูดได้หลายภาษาใหม่เรามักจะเริ่มต้นด้วย ET เพราะมันเป็นความคิดที่ดี เราติดกับมันจนกว่าเราจะพบปัญหามากเกินไปกับสิ่งที่ไม่เข้ากัน .. และในที่สุดเราก็เปลี่ยนกลับไปใช้วิธี D6 แบบเก่า