วิธีทดสอบเว็บไซต์ WordPress หลายภาษาก่อนเปิดใช้งาน

เริ่มจากชั้นของ URL และการกำหนดเส้นทาง

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

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

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

ตรวจสอบว่าการสลับภาษารักษาความสัมพันธ์ของเนื้อหาที่ถูกต้อง

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

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

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

ตรวจสอบความครบถ้วนของเนื้อหาในระดับอ็อบเจ็กต์

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

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

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

ตรวจสอบเมตาดาต้า canonical และ hreflang พร้อมกัน

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

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

ตรวจสอบเมตาดาต้าที่ไม่แสดงในเนื้อหาหน้าด้วย เช่น ฟิลด์ Open Graph ชื่อเรื่องสำหรับโซเชียล และเมตาดาต้าเชิงโครงสร้างใด ๆ ที่ธีมหรือปลั๊กอินสร้างขึ้น หากค่าดังกล่าวมาจาก post meta หรือฟิลด์การแปล ก็อาจคลาดเคลื่อนจากเนื้อหาที่มองเห็นได้ เว้นแต่จะรวมไว้ในเวิร์กโฟลว์การแปลอย่างชัดเจน

ทดสอบฟอร์มและโฟลว์ธุรกรรมในทุกภาษา

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

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

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

ตรวจสอบผลลัพธ์จากปลั๊กอินแบบไดนามิกและเนื้อหาที่ขับเคลื่อนด้วยเทมเพลต

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

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

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

ตรวจสอบพื้นผิว WooCommerce ให้เป็นประสบการณ์แยกตามภาษา

หน้าค้าขายต้องมากกว่าแค่คำอธิบายสินค้าที่แปลแล้ว ทดสอบหน้าคลังสินค้า หน้าสินค้าเดี่ยว ตะกร้า ชำระเงิน หน้าบัญชี การยืนยันคำสั่งซื้อ และข้อความในอีเมลหรือหน้าบัญชีที่ปรากฏหลังการซื้อ

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

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

ตรวจสอบพฤติกรรมบนมือถือในแต่ละภาษา ไม่ใช่แค่ภาษาเดียว

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

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

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

ยืนยันความสามารถในการถูกครอว์ลและการจัดทำดัชนีก่อนเปิดใช้งาน

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

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

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