01.02 คือ 1 กุมภาพันธ์หรือ 2 มกราคม? กับดักในการปรับเนื้อหาให้เข้ากับท้องถิ่นที่อาจทำให้เสียเงิน

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

วันที่และเวลา: วันเดียวกัน แต่อ่านได้สามแบบ

ลำดับส่วนประกอบของวันที่แตกต่างกันไปในแต่ละประเทศ รัสเซีย เยอรมนี และประเทศส่วนใหญ่ในยุโรปใช้รูปแบบ «วัน.เดือน.ปี» ส่วนในสหรัฐอเมริกาจะเขียนเดือนก่อน ดังนั้น «03/04/2025» จึงหมายถึงวันที่ 4 มีนาคม ไม่ใช่ 3 เมษายน ส่วนญี่ปุ่น จีน และเกาหลีใช้ลำดับกลับกัน คือเริ่มจากปี ตามด้วยเดือนและวัน

เรื่องเวลาก็เช่นกัน รัสเซีย ประเทศส่วนใหญ่ในยุโรป และลาตินอเมริกาคุ้นเคยกับรูปแบบ 24 ชั่วโมง ขณะที่สหรัฐอเมริกา แคนาดา ออสเตรเลีย และอินเดียใช้รูปแบบ 12 ชั่วโมงพร้อมสัญลักษณ์ AM และ PM กันอย่างแพร่หลาย การเขียน «5:00» โดยไม่ระบุเพิ่มเติมอาจอ่านได้ต่างกันไปในแต่ละประเทศ และการนัดพบตอน «ห้าโมง» ก็อาจคลาดเคลื่อนไปถึงสิบสองชั่วโมงจากเวลาที่ตั้งใจไว้

เพื่อไม่ให้ต้องคาดเดา ควรใช้มาตรฐาน ISO 8601 กับข้อมูลและ API (เช่น 2025-02-01T14:30) ส่วนในอินเทอร์เฟซให้แสดงวันที่โดยใช้เครื่องมือที่อิงตามการตั้งค่าภูมิภาค แทนการพิมพ์รูปแบบวันที่เอง

ตัวคั่นในตัวเลข: ใช้จุลภาคแทนจุด

ตัวเลข «1 500,75» ในรัสเซียและ «1,500.75» ในสหรัฐอเมริกามีค่าเท่ากัน ในเยอรมนีและบราซิลใช้จุดคั่นหลักพัน และใช้จุลภาคคั่นทศนิยม: «1.500,75» ส่วนในสวิตเซอร์แลนด์ใช้เครื่องหมายอะพอสทรอฟี: «1'500.75» อินเดียจัดกลุ่มตัวเลขอีกแบบ โดย «1,00,000» หมายถึงหนึ่งแสน

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

สกุลเงิน: สัญลักษณ์ ตำแหน่ง และการปัดเศษ

สัญลักษณ์สกุลเงินอาจดูเป็นเรื่องเล็กน้อย แต่ก็ทำให้สับสนได้ง่าย เครื่องหมาย «$» ใช้ในสหรัฐอเมริกา แคนาดา ออสเตรเลีย และอีกหลายประเทศ ดังนั้นหากไม่มีรหัสสกุลเงิน «$» อาจหมายถึงดอลลาร์ของประเทศใดก็ได้ ด้วยเหตุนี้ ในบริบทระหว่างประเทศจึงนิยมระบุรหัสสามตัวอักษรตามมาตรฐาน ISO 4217 เช่น USD, EUR, RUB

ตำแหน่งของสัญลักษณ์ก็แตกต่างกันไป ประเทศที่ใช้ภาษาอังกฤษเขียน «$100» ส่วนในฝรั่งเศสเขียน «100 €» โดยเว้นวรรคแบบไม่ตัดบรรทัด และในรัสเซียเขียน «100 ₽» หรือ «100 руб.» บางครั้งข้อผิดพลาดเกิดขึ้นระหว่างการแปล: วลี «ราคารวมภาษีมูลค่าเพิ่มแล้ว» อาจต้องใช้โครงสร้างประโยคที่ต่างกันในอีกภาษา หากประกอบข้อความจากหลายส่วนโดยแทรกจำนวนเงินเข้าไป ลำดับคำก็อาจผิดเพี้ยนได้

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

ระบบเมตริกและระบบอิมพีเรียล

คนส่วนใหญ่ในโลกใช้ระบบเมตริก แต่สหรัฐอเมริกาใช้ฟุต ปอนด์ แกลลอน และองศาฟาเรนไฮต์ ในสหราชอาณาจักร ป้ายจราจรระบุระยะทางเป็นไมล์ และนมขายเป็นไพนต์ ซึ่งไพนต์ของที่นั่นมีปริมาตรมากกว่าของสหรัฐฯ คือประมาณ 568 มิลลิลิตร เทียบกับประมาณ 473 มิลลิลิตร แกลลอนก็มีขนาดต่างกันไปคนละฝั่งของมหาสมุทรแอตแลนติกเช่นกัน

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

หมายเลขโทรศัพท์ ที่อยู่ และชื่อในแบบฟอร์ม

แบบฟอร์มลงทะเบียนมักมีปัญหาอยู่สามช่อง ช่องแรกคือหมายเลขโทรศัพท์: ในรัสเซียอาจเขียนเป็น «+7 (999) 123-45-67» ส่วนในเยอรมนีหมายเลขโทรศัพท์มีความยาวไม่ตายตัว และรูปแบบที่กำหนดจำนวนตัวเลขไว้ตายตัวหลายแบบก็ไม่รองรับ ควรใช้ช่องที่ให้เลือกใช้รหัสประเทศและไลบรารีสำหรับตรวจสอบหมายเลข

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

ช่องที่สามคือชื่อและนามสกุล: ในสเปนและลาตินอเมริกามักมีนามสกุลสองชื่อ ส่วนในไอซ์แลนด์จะใช้ชื่อบิดาแทนนามสกุล และบางคนก็มีชื่อเพียงชื่อเดียว เครื่องหมายอะพอสทรอฟีในนามสกุล «O'Brien» หรือยัติภังค์ไม่ควรทำให้ระบบแจ้งข้อผิดพลาด ข้อกำหนดขั้นต่ำง่าย ๆ คืออย่าบังคับให้กรอกสองช่องในกรณีที่ไม่จำเป็น และรองรับอักขระ Unicode ทุกชนิด

วิธีหลีกเลี่ยงข้อผิดพลาด: มาตรฐานและการทดสอบ

การจัดการรูปแบบต่าง ๆ ไม่ได้เริ่มต้นตอนตรวจสอบ แต่เริ่มตั้งแต่ขั้นตอนออกแบบ สิ่งที่ช่วยได้มีดังนี้:

• จัดเก็บวันที่ในรูปแบบ ISO 8601 ตัวเลขโดยไม่จัดรูปแบบ และสกุลเงินพร้อมรหัส ISO 4217 ส่วนการแสดงผลให้การตั้งค่าภูมิภาคเป็นผู้จัดการ
• ใช้ไลบรารีมาตรฐานสำหรับการปรับเนื้อหาให้เข้ากับท้องถิ่น แทนการสร้างรูปแบบขึ้นเอง เช่น ICU หรือเครื่องมือที่มีมาให้ในแพลตฟอร์ม
• ให้ข้อมูลบริบทแก่นักแปล: ข้อความควรระบุหน่วย สกุลเงิน และประเภทของวันที่ให้ชัดเจน ไม่ใช่มีเพียงคำศัพท์เท่านั้น
• ทดสอบอินเทอร์เฟซด้วยวันที่และตัวเลข เช่น 01.02, 12:00 และ 1 000,50 ในการตั้งค่าภูมิภาคหลายแบบ รวมถึงแบบที่ใช้ลำดับต่างกัน
• ให้เจ้าของภาษาตรวจสอบขั้นสุดท้าย พวกเขาจะสังเกตได้เร็วกว่าเมื่อพบว่าเขียน «ห้าโมงเย็น» เป็น «17.00» ในพื้นที่ที่ไม่มีใครพูดแบบนั้น

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

อ่านเพิ่มเติม:

• การปรับเว็บไซต์และแอปให้เข้ากับท้องถิ่น: แตกต่างจากการแปลทั่วไปอย่างไร
• การแปลร้านค้าออนไลน์: ควรปรับเนื้อหาส่วนใดก่อน และทำตามลำดับใด

ต้องการงานแปลมืออาชีพใช่ไหม? สั่งแปลออนไลน์: เลือกภาษา อัปโหลดไฟล์ และทราบราคาได้ภายในไม่กี่นาที

บทความที่เกี่ยวข้อง

• ทำไมข้อความจึง “ยาวขึ้น” เมื่อแปล และควรคำนึงถึงเรื่องนี้ในการออกแบบอย่างไร
• การแปลเอกสารทางการเงิน: ลักษณะเฉพาะและความสำคัญต่อบริษัท