การแปลด้วยเครื่องไม่เหมือนกับวิศวกรรมเนื้อหาหลายภาษา

การแปลเปลี่ยนข้อความ แต่วิศวกรรมหลายภาษาเปลี่ยนทั้งระบบ

การแปลด้วยเครื่องสามารถแทนที่สำเนาภาษาเดิมด้วยสำเนาอีกภาษาได้ แต่เพียงเท่านั้นยังไม่ทำให้เว็บไซต์ WordPress เป็นหลายภาษาอย่างน่าเชื่อถือ ระบบหลายภาษาต้องรักษาวิธีการประกอบเนื้อหา วิธีการระบุ วิธีการกำหนดเส้นทาง และวิธีการซิงโครไนซ์ระหว่างเวอร์ชันภาษา

ใน WordPress นั่นหมายความว่าหน้าแปลแล้วไม่ใช่แค่ก้อนข้อความธรรมดา อาจถูกสร้างจากบล็อก เทมเพลต เมตาของโพสต์ ฟิลด์กำหนดเอง ข้อมูลที่ปลั๊กอินเป็นเจ้าของ และผลลัพธ์แบบไดนามิก หากแปลเฉพาะสตริงที่มองเห็นได้ หน้าเว็บก็ยังอาจเสียโครงสร้าง สูญเสียความสัมพันธ์ หรือแสดงเมตาดาตาที่ไม่สอดคล้องกันระหว่างภาษาได้

โครงสร้างหน้าต้องรอดจากการแปล

หน้าหลายภาษาต้องการมากกว่าประโยคที่แปลแล้วภายในตัวแก้ไขเนื้อหา โครงสร้างพื้นฐานมีความสำคัญ เพราะแต่ละภาษาสามารถเปลี่ยนความยาวของข้อความ ลำดับการอ่าน และวิธีที่บล็อกหรือส่วนของเทมเพลตประกอบเข้าด้วยกันได้

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

สำหรับผู้พัฒนา WordPress คำถามเชิงปฏิบัติคือเวิร์กโฟลว์การแปลรักษาโมเดลเนื้อหาต้นฉบับไว้ได้หรือไม่ หากหน้าหนึ่งพึ่งพาเทมเพลต รูปแบบบล็อก หรือฟิลด์ที่มีโครงสร้าง เวอร์ชันภาษาทุกเวอร์ชันต้องคงสัญญาเชิงโครงสร้างเดียวกัน แม้ถ้อยคำจะเปลี่ยนไปก็ตาม

เมตาดาตาเป็นส่วนหนึ่งของเนื้อหา ไม่ใช่เรื่องที่คิดทีหลัง

วิศวกรรมเนื้อหาหลายภาษาต้องคำนึงถึงเมตาดาตา เช่น ชื่อเรื่อง คำอธิบาย สลัก ฟิลด์กำหนดเอง และค่าที่ไวต่อภาษาอื่น ๆ ฟิลด์เหล่านี้มีผลต่อวิธีแสดงหน้า การจัดทำดัชนี และการเชื่อมโยง ดังนั้นหากปล่อยให้ไม่แปลหรือไม่ซิงโครไนซ์ ก็อาจทำให้เวอร์ชันภาษาต่าง ๆ ไม่ตรงกัน

เนื้อหาหลักที่แปลแล้วแต่ชื่อเรื่องหรือสลักยังไม่แปล อาจทำให้ทั้งผู้ใช้และเครื่องมือค้นหาสับสน หน้าอาจดูเหมือนถูกปรับให้เป็นภาษาท้องถิ่นในตัวแก้ไข แต่ยังแสดงภาษาไม่ถูกต้องในเมนูนำทาง ตัวอย่างผลการค้นหา หรือการเชื่อมโยงภายใน

เรื่องนี้สำคัญเป็นพิเศษเมื่อเมตาดาตาถูกเก็บแยกจากเนื้อหาหลัก เว็บไซต์ WordPress มักกระจายข้อมูลไปตามเมตาของโพสต์ ฟิลด์กำหนดเอง และข้อมูลที่ปลั๊กอินเป็นเจ้าของ ดังนั้นเวิร์กโฟลว์การแปลต้องรู้ว่าฟิลด์ใดเฉพาะภาษา และฟิลด์ใดควรใช้ร่วมกัน

เนื้อหาแบบไดนามิกต้องเรนเดอร์โดยคำนึงถึงภาษา

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

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

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

URL การกำหนดเส้นทาง และสัญญาณแคนนอนิคัลต้องสอดคล้องกัน

เว็บไซต์ WordPress หลายภาษายังเป็นปัญหาเรื่องการกำหนดเส้นทางด้วย แต่ละเวอร์ชันภาษาต้องมีรูปแบบ URL ที่เสถียร การนำทางที่คาดเดาได้ และความสัมพันธ์ที่ชัดเจนกับเวอร์ชันอื่นของเนื้อหาเดียวกัน

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

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

การซิงโครไนซ์คือความแตกต่างเชิงปฏิบัติการระหว่างการแปลกับระบบ

หน้าที่แปลแล้วอาจค่อย ๆ เบี่ยงเบนจากต้นฉบับได้ หากไม่มีการส่งต่อการอัปเดตอย่างมีการควบคุม การเบี่ยงเบนนั้นอาจกระทบสำเนา เมตาดาตา ลิงก์ ความสัมพันธ์เชิงโครงสร้าง และการอ้างอิงแบบไดนามิก

คำถามเชิงปฏิบัติการไม่ใช่แค่ว่ามีการแปลหรือไม่ แต่คือมันยังสอดคล้องกันอยู่หรือไม่เมื่อเนื้อหาต้นฉบับเปลี่ยนไป หากหน้าเดิมถูกแก้ไขหลังการแปล ระบบหลายภาษาต้องมีวิธีตรวจจับว่าส่วนใดเปลี่ยนไป ส่วนใดต้องแปลใหม่ และส่วนใดสามารถใช้ร่วมกันต่อได้

นี่คือจุดที่วิศวกรรมเนื้อหาหลายภาษากลายเป็นวินัยด้านการบำรุงรักษา ทีมงานต้องมีกฎสำหรับการเป็นเจ้าของแหล่งข้อมูลต้นทาง การส่งต่อการอัปเดต และการตรวจทาน หากไม่มี กฎเหล่านี้ เว็บไซต์จะสะสมการแปลบางส่วน เมตาดาตาล้าสมัย และเวอร์ชันภาษาที่ไม่สอดคล้องกัน ซึ่งตรวจสอบย้อนหลังได้ยาก

การเชื่อมต่ออาจเสียได้แม้หน้าจะดูเหมือนแปลแล้ว

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

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

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

การตรวจสอบต้องทดสอบพฤติกรรม ไม่ใช่แค่คุณภาพภาษา

การตรวจสอบเชิงปฏิบัติการสำหรับ WordPress หลายภาษาควรตรวจมากกว่าว่าการแปลอ่านลื่นหรือไม่ ควรยืนยันว่าโครงสร้างหน้าถูกต้อง เมตาดาตามีครบ URL ทำงานถูกต้อง ความสัมพันธ์แบบแคนนอนิคัลและภาษาเชื่อมโยงกันอย่างสอดคล้อง และเนื้อหาแบบไดนามิกแสดงในภาษาที่ถูกต้อง

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

นี่คือเส้นแบ่งเชิงปฏิบัติระหว่างการแปลด้วยเครื่องกับวิศวกรรมเนื้อหาหลายภาษา: การแปลสร้างเอาต์พุตภาษา ส่วนการตรวจสอบพิสูจน์ว่าเอาต์พุตนั้นยังทำงานเหมือนหน้า WordPress ที่ถูกต้องในทุกภาษาที่รองรับ