เว็บไซต์เดียว หลายสิบภาษา: i18n สำหรับอีคอมเมิร์ซในทางปฏิบัติ

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

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

โครงสร้าง URL: การตัดสินใจที่เปลี่ยนภายหลังได้ยากที่สุด

โครงสร้าง URL สำหรับเว็บไซต์หลายภาษาเป็นการตัดสินใจแรกและย้อนกลับได้ยากที่สุด มีสามแนวทางที่ใช้กันจริง: แยกโดเมนตามภาษาและภูมิภาค (example.de, example.fr) แยกซับโดเมน (de.example.com, fr.example.com) และแยกไดเรกทอรีย่อย (example.com/de/, example.com/fr/) แต่ละแนวทางมีผลต่อความน่าเชื่อถือของโดเมนด้าน SEO ความซับซ้อนในการนำระบบขึ้นใช้งาน และภาระดำเนินงานต่างกัน

การแยกโดเมนให้ประสบการณ์ผู้ใช้ที่ชัดเจนที่สุดและแยกการโฮสต์แต่ละตลาดได้อย่างอิสระ แต่ทำให้ความน่าเชื่อถือของโดเมนกระจายออกไป ประโยชน์จากลิงก์ย้อนกลับที่สะสมหลายปีให้ example.com ไม่ได้ส่งต่อไปยัง example.de โดยตรง สำหรับเว็บไซต์ที่มีผู้เข้าชมจากการค้นหาอยู่แล้ว นี่คือต้นทุนที่สูง ส่วนเว็บไซต์ใหม่ที่มุ่งตลาดซึ่งโดเมนระดับบนท้องถิ่นช่วยสร้างความเชื่อถือ อาจต้องพิจารณาต่างออกไป

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

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

ไปป์ไลน์แปลภาษา

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

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

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

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

hreflang: การนำไปใช้และข้อผิดพลาดที่พบบ่อย

แท็ก hreflang บอกเครื่องมือค้นหาว่าควรแสดงหน้าภาษาและภูมิภาคใดให้ผู้ใช้แต่ละกลุ่ม วิธีทำในเอกสารดูตรงไปตรงมา: เพิ่มชุดแท็ก <link rel="alternate"> ในแต่ละหน้า หนึ่งแท็กต่อภาษาและภูมิภาค โดยใช้รหัสภาษาที่ถูกต้อง (รหัสภาษา ISO 639-1 ซึ่งอาจตามด้วยรหัสภูมิภาค ISO 3166-1 alpha-2 เช่น de หรือ de-AT) แต่ในทางปฏิบัติมีจุดที่ผิดพลาดได้มากจนการตั้งค่า hreflang ผิดกลายเป็นเรื่องปกติมากกว่าข้อยกเว้น

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

ข้อผิดพลาดที่พบบ่อยรองลงมาคือค่า hreflang ไม่ตรงกัน เช่น แท็กบนหน้าภาษาอังกฤษชี้ไป /de/product-name แต่ URL หลักของหน้าภาษาเยอรมันคือ /de/produktname ปัญหานี้เกิดเมื่อแปลส่วนชื่อหน้าใน URL ซึ่งควรทำเพื่อ SEO ในตลาดที่คำค้นภาษาท้องถิ่นสำคัญ แต่ไม่อัปเดต hreflang ตามไปด้วย การตรวจอัตโนมัติโดยไล่เก็บหน้าเว็บและยืนยันว่าแท็ก hreflang ทุกแท็กชี้ไป URL หลักที่มีอยู่จริง เป็นวิธีเดียวที่ตรวจพบความไม่สอดคล้องเหล่านี้ได้อย่างน่าเชื่อถือในเว็บไซต์ขนาดใหญ่

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

RTL: มากกว่าการกลับด้านโครงร่าง

การรองรับภาษาที่อ่านจากขวาไปซ้าย สำหรับภาษาอาหรับ ฮีบรู เปอร์เซีย (ฟาร์ซี) อูรดู และระบบการเขียนจากขวาไปซ้ายอื่น ๆ มักถูกมองว่าเป็นปัญหา CSS: เพิ่ม dir="rtl" ในองค์ประกอบราก สลับทิศทาง flex กลับค่า padding และ margin แล้วถือว่าเสร็จ แต่การรองรับ RTL จะเผยสมมติฐานด้านโครงร่างที่มองไม่เห็นจนกว่าทิศทางจะเปลี่ยน

ทิศทางของไอคอนเป็นสิ่งที่มักตกหล่นที่สุด ลูกศรนำทาง ตัวบอกความคืบหน้า และไอคอนที่ชี้ซ้ายหรือขวามีความหมายซึ่งควรกลับด้านในบริบท RTL ลูกศร “ย้อนกลับ” ที่ชี้ซ้ายใน LTR ควรชี้ขวาใน RTL การใช้ CSS transform: scaleX(-1) กลับด้านได้ในเชิงกลไก แต่ต้องตรวจไอคอนที่มีทิศทางทุกตัวในส่วนติดต่อผู้ใช้ เพื่อให้กลับด้านเฉพาะเมื่อเหมาะสม

ตัวเลข หมายเลขโทรศัพท์ และรหัสไปรษณีย์ยังคงอ่านจากซ้ายไปขวาแม้อยู่ในข้อความ RTL และไม่ควรกลับด้าน เนื่องจากอัลกอริทึมจัดข้อความสองทิศทางของ Unicode จัดตัวเลขและตัวคั่นเป็นอักขระทิศทางอ่อนหรือเป็นกลาง ตำแหน่งจึงขึ้นอยู่กับข้อความรอบข้าง ค่าต่าง ๆ เหล่านี้จึงมักต้องแยกทิศทางออกจากข้อความรอบข้าง เช่น ใช้ <bdi> หรือ dir="ltr" การผสมข้อความ LTR และ RTL ในกลุ่มข้อความเดียว เช่น คำอธิบายสินค้าที่มีหมายเลขรุ่น ต้องใช้ตัวควบคุมทิศทาง Unicode อย่างชัดเจน หรือใช้แอตทริบิวต์ HTML dir อย่างระมัดระวัง เพื่อป้องกันอัลกอริทึมจัดข้อความสองทิศทางของเบราว์เซอร์แสดงผลผิดเพี้ยน

การปรับให้เข้ากับวัฒนธรรมที่มากกว่าการแปล

การปรับให้เหมาะกับตลาดและการแปลไม่ใช่งานเดียวกัน การแปลเปลี่ยนถ้อยคำ ส่วนการปรับให้เหมาะกับตลาดเปลี่ยนความหมายที่ผู้รับสารเข้าใจ จึงต้องเข้าใจบริบททางวัฒนธรรมที่กำหนดว่าข้อความหนึ่งมีความหมายอย่างไรต่อผู้ชมกลุ่มนั้น

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

วิธีชำระเงินเป็นอีกมิติทางวัฒนธรรมที่มักถูกจัดการในฐานะงานเชื่อมต่อทางเทคนิค แทนที่จะเป็นเรื่องการปรับให้เหมาะกับตลาด ในเยอรมนี การโอนเงินผ่านธนาคาร (Überweisung) และการหักบัญชีโดยตรงผ่าน SEPA ยังเป็นช่องทางซื้อที่สำคัญ ในญี่ปุ่น การชำระเงินที่ร้านสะดวกซื้อยังมีการใช้งานมาก การให้เพียงบัตรเครดิตกับ PayPal ในตลาดเหล่านี้จึงไม่ใช่ความล้มเหลวด้านการแปล แต่เป็นความล้มเหลวในการรองรับวิธีซื้อที่ลูกค้าใช้จริง

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