ความเข้ากันได้ของปลั๊กอิน WordPress ในเว็บไซต์หลายภาษา: อะไรที่ต้องทดสอบจริงๆ?

เริ่มจากแยกสิ่งที่ผู้ใช้เห็นออกจากสิ่งที่ผู้ดูแลระบบตั้งค่า

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

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

ทดสอบส่วนของเนื้อหาที่เปลี่ยนไปตามภาษาโดยตรง

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

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

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

ตรวจสอบเอาต์พุตแบบไดนามิก ไม่ใช่แค่เนื้อหาที่บันทึกไว้

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

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

สถานะฝั่งหน้าเว็บก็อยู่ในหมวดนี้เช่นกัน อะไรก็ตามที่ขึ้นอยู่กับหน้าปัจจุบัน, ภาษาที่เลือก, สถานะฟอร์ม, หรือบริบทของสินค้า อาจล้มเหลวได้หากปลั๊กอินสมมติว่ามีเซสชันภาษาเดียว เว็บไซต์หลายภาษาควรถูกทดสอบเรื่องการรั่วไหลของสถานะ ซึ่งการเลือก, ผลการตรวจสอบ, หรือสถานะ UI ของภาษาหนึ่งไปปรากฏในบริบทของอีกภาษา

ฟอร์มต้องมีการตรวจสอบ, ป้ายกำกับ, และการจัดการการส่งที่คำนึงถึงภาษา

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

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

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

WooCommerce เพิ่มความซับซ้อนด้านสินค้า, ตะกร้า, และการชำระเงิน

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

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

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

ถือว่าเส้นทาง, พาร์มาลิงก์, และสัญญาณ canonical เป็นส่วนหนึ่งของความเข้ากันได้

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

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

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

ใช้เมทริกซ์การทดสอบที่ไล่ตามข้อมูล, การเรนเดอร์, และสถานะ

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

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

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