การให้คำปรึกษาด้าน Internationalization: แก้ไขสิ่งที่กำลังมีปัญหา วางแผนสิ่งที่จะเกิดขึ้นต่อไป
คุณก็รู้อยู่แล้วว่า i18n นั้นยาก ผมเคยเห็นอาการเหล่านี้มาหมดแล้ว: เลย์เอาต์ RTL ที่พังทลาย ข้อความภาษาเยอรมันที่ล้นออกนอกปุ่ม การตอบกลับ API ที่มาผิดภาษา และงานแปลที่เริ่มไม่ตรงกันภายในไม่กี่สัปดาห์หลังเปิดตัว ผมไม่ได้ขายสูตรสำเร็จวิเศษอะไร แต่ผมช่วยคุณแก้ปมปัญหาเฉพาะที่ทีมของคุณกำลังเผชิญอยู่ และสร้างระบบที่จะไม่พังซ้ำแบบเดิมอีก
"เราน่าจะวางแผนเรื่องนี้เร็วกว่านี้"
ภาษีสถาปัตยกรรมที่คุณกำลังจ่ายอยู่ตอนนี้
คุณเปิดตัวเป็นภาษาอังกฤษ ใช้ได้ดี จากนั้นก็เพิ่มภาษาฝรั่งเศส 'แค่สำหรับหน้า Landing Page' ตอนนี้คุณมาอยู่ที่นี่เพราะ:
โค้ดเบสของคุณมีการตรวจสอบ lang= กระจายอยู่ใน 47 ไฟล์
ผู้จัดการผลิตภัณฑ์ถามว่า "เราทดสอบ A/B ข้อความได้ไหม?" และฝ่ายวิศวกรรมบอกว่า "ไม่ได้ถ้าไม่เขียนใหม่"
คุณมีเวิร์กโฟลว์การแปลถึงสามแบบที่แตกต่างกัน แต่ไม่มีสักอันที่ทำงานได้อย่างน่าเชื่อถือ
สิ่งที่ผมเคยเห็นว่ามีปัญหา:
- หลายทีมใช้เวลามากกว่า 6 เดือนในการปรับปรุง i18n ในแอป Next.js เพราะสตริงถูกฮาร์ดโค้ดในคอมโพเนนต์
- ไฟล์การแปลหลุดจากการซิงค์เพราะนักพัฒนาไม่รู้ว่าต้องอัปเดตไฟล์ไหน
- ช่วง "ล็อกการแปลภาษา" ก่อนรีลีสเพราะไม่มีใครเชื่อถือไปป์ไลน์การแปล
- การต่อต้านการเปลี่ยนแปลงเนื้อหาที่แปลแล้ว เพราะเวิร์กโฟลว์นั้นยุ่งยากมาก
สิ่งที่ผมช่วยได้:
- กลยุทธ์การปรับโครงสร้างโค้ดที่ให้คุณนำ i18n มาใช้ทีละน้อย (ผมไม่ได้เรียกร้องให้ "หยุดทุกอย่างแล้วเขียนใหม่")
- การออกแบบกระบวนการเพื่อให้การแปลซิงค์กันโดยไม่บล็อกการพัฒนา
- ตรวจสอบสถาปัตยกรรมเพื่อระบุจุดที่แนวทางปัจจุบันของคุณจะเกิดปัญหาเมื่อรองรับ 10 ภาษาขึ้นไป
i18n คือสถาปัตยกรรม ไม่ใช่ฟีเจอร์ การพยายามเพิ่มมันทีหลังก็เหมือนกับการตัดสินใจว่าบ้านของคุณต้องการชั้นใต้ดินหลังจากที่สร้างเสร็จแล้ว
ผมช่วยคุณขุดห้องใต้ดินนั้น หรือช่วยตัดสินใจว่าคุณต้องการมันจริงๆ หรือเปล่า
RTL ทำให้ทุกอย่างพัง
UI ของคุณไม่ได้ออกแบบมาสำหรับภาษาอาหรับ ฮีบรู หรืออูรดู
คุณเปลี่ยน dir="rtl" แล้วดูเลย์เอาต์ของคุณพังทลาย:
สิ่งที่เจอมา:
- ระบบออกแบบที่มีคอมโพเนนต์มากกว่า 200 รายการ ซึ่งมีเพียง 12 ที่จัดการ RTL ได้อย่างถูกต้อง
- ทีมที่ใช้ float: left แทนที่จะเป็น logical properties สร้างบั๊ก RTL ในทุกฟีเจอร์ใหม่
- ป๊อปโอเวอร์และโมดัลที่ต้องใช้การแทนที่ RTL เฉพาะคอมโพเนนต์
- เฟรมเวิร์กที่อ้างว่ามีการรองรับ RTL แต่กลับแค่พลิกทิศทางการจัดวาง และทำให้ตรรกะการจัดวางเสียหาย
สิ่งที่ผมช่วยได้:
- การย้ายไปใช้ CSS logical properties (margin-inline-start แทน margin-left)
- การตรวจสอบระบบออกแบบเพื่อค้นหาจุดเสี่ยงด้าน RTL ก่อนปล่อยใช้งาน
- คำแนะนำเฉพาะเฟรมเวิร์ก (Tailwind, shadcn, MUI) สำหรับการจัดรูปแบบที่เน้น RTL เป็นอันดับแรก
การแก้ไขบั๊ก RTL ด้วยตนเองในทุกคอมโพเนนต์ไม่ยั่งยืน ผมทำให้การสนับสนุน RTL เป็นระบบ ไม่ใช่การดับเพลิงตลอดเวลา
"ข้อความภาษาเยอรมันทำให้ปุ่มของเราพัง"
UI ที่ไม่ได้สร้างมาเพื่อรองรับการแปล
ภาษาอังกฤษเข้ากันได้ดี ภาษาเยอรมันไม่เข้ากัน การออกแบบของคุณสมมติว่า:
แล้วคุณก็แปลเป็นภาษาเยอรมัน ภาษาฟินนิช หรือภาษาไทย และค้นพบว่า:
ข้อความบนปุ่มถูกตัดกลางคำ
ตารางที่มีแถบเลื่อนแนวนอนในทุกแถว
ข้อความที่ขึ้นบรรทัดใหม่เป็นบล็อกที่อ่านไม่ออก
ข้อความที่ไม่ใช่ภาษาละตินถูกตัดทอนเนื่องจากคอนเทนเนอร์มีความกว้างคงที่
สิ่งที่ผมช่วยได้:
- รูปแบบ UI ที่ยืดหยุ่นซึ่งปรับตามความยาวของเนื้อหา
- การวางแผนงบประมาณตัวอักษร (เมื่อรู้ว่าภาษาเยอรมันจะยาวขึ้น 30% ภาษาไทยไม่ใช้ช่องว่าง)
- ระบบการจัดพิมพ์ที่สามารถจัดการ CJK ภาษาอาหรับ และเทวนาครี ได้โดยไม่มีปัญหา
ผมช่วยคุณสร้าง UI ที่รอดจากการแปลได้—ก่อนที่คุณจะจ่ายเงินไปกับ 10,000 คำที่ใส่ไม่ลง
คุณไม่ต้องการให้ใครมาบรรยายว่าทำไม i18n ถึงสำคัญ คุณต้องการคนที่ดีบัก RTL popovers ตอนตี 2 โต้เถียงกับฝ่ายผลิตภัณฑ์เรื่องงบประมาณตัวอักษร และออกแบบไปป์ไลน์การแปลที่ทำงานได้จริง
ปัญหาที่ไม่มีใครเตือนไว้ก่อน
เรื่องเล่าจากประสบการณ์ของหลายทีมที่เคยผ่านมาแล้ว
สิ่งเหล่านี้ไม่ใช่แค่ทฤษฎี แต่เป็นสิ่งที่เคยมีปัญหาในการใช้งานจริง:
นรกของการผันพหูพจน์
ภาษาอังกฤษ: "1 item" vs "2 items"
ภาษาโปแลนด์: "1 przedmiot" / "2 przedmioty" / "5 przedmiotów" (3 รูปแบบพหูพจน์)
ภาษาอาหรับ: 6 รูปแบบพหูพจน์
ลอจิก count === 1 ? 'item' : 'items' ของคุณใช้ไม่ได้แล้ว
ความวุ่นวายของวันที่/เวลา
คุณจัดรูปแบบวันที่ด้วย toLocaleDateString() จากนั้นผู้ใช้ในญี่ปุ่นเห็น "2025年2月9日" ในไฟล์ CSV ที่ส่งออกของคุณ และ Excel ก็มีปัญหา
ภาษาของ API ไม่ตรงกัน
ส่วนหน้าของคุณขอภาษาฝรั่งเศส แต่ API ส่งภาษาอังกฤษกลับมาเพราะ auth token ไม่มีข้อมูล locale ตอนนี้คุณมี UI ที่ปนกันสองภาษา และผู้ใช้คิดว่ามันเป็นบั๊ก
การทดสอบ Pseudo-Locale
คุณไม่ได้ทดสอบด้วย [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30%] ก่อนนำขึ้นโปรดักชัน ตอนนี้เว็บไซต์ภาษาโปแลนด์ของคุณใช้งานไม่ได้แล้ว
สมมติฐานที่มองไม่เห็น
คุณคิดว่ามีแค่ข้อความเท่านั้นที่ต้องแปล แต่แล้วคุณก็เจอปัญหากับวันที่ ตัวเลข สกุลเงิน การเรียงลำดับ การค้นหา ทุกอย่างล้วนมีพฤติกรรมเฉพาะตามภาษาและท้องถิ่น
สิ่งที่ผมช่วยได้:
- การนำ ICU MessageFormat ไปใช้ (จัดการพหูพจน์ เพศ บริบท)
- รูปแบบ i18n ของ API (การเจรจาภาษา, กลยุทธ์ fallback)
- กระบวนการ QA ที่จับปัญหาเหล่านี้ได้ก่อนที่บริษัทรับแปลจะเจอ
เวิร์กโฟลว์คือส่วนที่ยาก
คุณจะรักษา 8 ภาษาให้ซิงค์กันได้อย่างไรเมื่อคุณส่งมอบทุกวัน?
คุณเข้าใจเทคโนโลยีแล้ว ตอนนี้คุณติดอยู่ที่กระบวนการ:
นักพัฒนารวมโค้ดที่มีข้อความภาษาอังกฤษใหม่เข้าไป การแปลตามมาช้ากว่า 2 สัปดาห์ ผู้ใช้เห็น UI ที่แปลไม่ครบ
คุณไม่รู้ว่าสตริงไหนปลอดภัยที่จะลบ (มันถูกใช้หรือไม่? ถูกแปลหรือไม่? อยู่ในระหว่างดำเนินการกับเอเจนซี่หรือไม่?)
ฝ่ายผลิตภัณฑ์ต้องการอัปเดตข้อความ ไม่มีใครรู้ว่าการเปลี่ยน "Submit" เป็น "Send" จะกระทบ 12 ภาษาหรือไม่
ไฟล์แปลไม่ตรงกับเวอร์ชันที่ใช้งานจริงเป็นเวลาหลายสัปดาห์
คำถามที่หลายทีมถามผม:
สิ่งที่ผมเคยเห็นว่ามีปัญหา:
- ไฟล์การแปลที่เช็คอินใน git ที่แตกต่างจากสตริงในโปรดักชัน
- คำเตือนว่า 'อย่าแตะไฟล์ภาษาสเปน' เพราะไม่มีใครรู้ว่าอะไรที่เปลี่ยนได้อย่างปลอดภัย
- ฟีเจอร์เปิดตัวเป็นภาษาอังกฤษ แล้วแปล 6 เดือนต่อมา (ถ้ามี)
สิ่งที่ผมช่วยได้:
- ออกแบบไปป์ไลน์การแปล (เมื่อใดที่ใช้ไลบรารี i18n เมื่อใดที่ใช้ TMS เมื่อใดที่ใช้ AI)
- เวิร์กโฟลว์ Git สำหรับการรักษาสตริงต้นฉบับและการแปลให้ซิงค์กัน
- ระบบอัตโนมัติที่บล็อก PR หากสตริงใหม่ไม่ได้ถูกทำเครื่องหมายสำหรับการแปล
เทคโนโลยีแก้ได้ เวิร์กโฟลว์ต่างหากที่เป็นตัวขัดขวาง ผมออกแบบเวิร์กโฟลว์ที่ไม่ต้องใช้ความพยายามมากเกินไปในการดูแลรักษา
ทีมที่เคยทำงานด้วย
ผลิตภัณฑ์ระดับโลก ความเชี่ยวชาญระดับภูมิภาค
LINE (ญี่ปุ่น, ไต้หวัน, ไทย)
แพลตฟอร์มส่งข้อความที่ดำเนินงานใน 3 ตลาดหลักในเอเชียตะวันออก ทำงานเกี่ยวกับความท้าทายเฉพาะด้านการจัดการอักขระ CJK การผสานระบบนิเวศของแพลตฟอร์ม และความคาดหวังด้านประสบการณ์ผู้ใช้ที่แตกต่างกันในญี่ปุ่น ไต้หวัน และไทย
KakaoTalk (เกาหลีใต้)
แพลตฟอร์มส่งข้อความที่ครองตลาดในเกาหลี ตอบสนองข้อกำหนดผลิตภัณฑ์เฉพาะของตลาดเกาหลี รวมถึงความคาดหวังด้านความเป็นทางการของภาษาใน UI และความต้องการในการผสานรวมแพลตฟอร์ม
Change.org (196 ประเทศ, ภาษาหลักมากกว่า 20 ภาษา)
แพลตฟอร์มยื่นคำร้องทั่วโลกที่ความเร็วของเนื้อหาและคุณภาพต่างก็สำคัญ ช่วยนำทางเวิร์กโฟลว์การแปลสำหรับเนื้อหาที่สร้างโดยผู้ใช้ทางการเมืองและสังคมในตลาดที่หลากหลาย
Airbnb (มากกว่า 220 ประเทศ, มากกว่า 60 ภาษา)
ตลาดระดับโลกที่มีความต้องการด้าน i18n ที่ซับซ้อน ให้คำปรึกษาเกี่ยวกับความท้าทายด้านความไว้วางใจและความปลอดภัยในหลายภาษา รวมถึงการปรับแนวคิดของแพลตฟอร์มให้เข้ากับวัฒนธรรมในแต่ละตลาด
Intercom (มากกว่า 30 ภาษา, SaaS B2B ระดับโลก)
แพลตฟอร์มการสื่อสารกับลูกค้าที่ให้บริการลูกค้าองค์กรระดับโลก ทำงานด้านการปรับผลิตภัณฑ์ให้เป็นสากลสำหรับเครื่องมือสนับสนุนแบบเรียลไทม์และการแปลฐานความรู้เป็นภาษาต่างๆ
Lilith Games (จีน, ญี่ปุ่น, เกาหลี, สหรัฐอเมริกา, สหภาพยุโรป)
ผู้จัดจำหน่ายเกมมือถือที่มีเกมเผยแพร่ไปทั่วโลก จัดการกับความท้าทายเฉพาะเจาะจงของตลาดเกี่ยวกับการแปลเนื้อหาและข้อกำหนดแพลตฟอร์มระดับภูมิภาค
ตลาดที่ผมเคยเปิดตัวมาแล้ว:
เอเชียตะวันออก (ญี่ปุ่น, เกาหลี, จีน):
การจัดพิมพ์ตัวอักษรของ CJK, การผสานรวมระบบนิเวศแพลตฟอร์ม, การรองรับข้อความแนวตั้ง
เอเชียตะวันออกเฉียงใต้ (ไทย, เวียดนาม, อินโดนีเซีย):
รองรับหลายสคริปต์ ความคาดหวังของผู้ใช้ที่เน้นมือถือเป็นอันดับแรก
MENA (ภูมิภาคที่พูดภาษาอาหรับ):
ข้อกำหนดเลย์เอาต์ RTL ความคาดหวังด้านภาษาทางการและภาษาพูด การปรับเนื้อหาให้เหมาะสมกับวัฒนธรรม
ยุโรป:
24 ภาษาทางการ การเปิดตัวผลิตภัณฑ์ในหลายประเทศ
อเมริกา:
ความแตกต่างของภาษาในแต่ละภูมิภาค (สเปนแบบละตินอเมริกา vs สเปนแบบยุโรป โปรตุเกสบราซิล) ตลาดสองภาษา
ผมได้เห็นแล้วว่าอะไรได้ผลและอะไรล้มเหลวในตลาดเหล่านี้ ไม่ใช่จากทฤษฎี แต่จากการส่งมอบผลิตภัณฑ์ที่ผู้ใช้จริงพึ่งพา
มาแก้ไขสิ่งที่กำลังมีปัญหากันเถอะ
คุณไม่ต้องการให้ใครมาบรรยายว่าทำไม i18n ถึงสำคัญ คุณต้องการคนที่ดีบัก RTL popovers ตอนตี 2 โต้เถียงกับฝ่ายผลิตภัณฑ์เรื่องงบประมาณตัวอักษร และออกแบบไปป์ไลน์การแปลที่ทำงานได้จริง
การตรวจทานสถาปัตยกรรมและกลยุทธ์ (1-2 สัปดาห์):
บอกให้รู้ว่าอะไรจะพังเมื่อคุณเพิ่มอีก 3 ภาษาถัดไป และจะต้องใช้ค่าใช้จ่ายเท่าไหร่ในการแก้ไข
การสนับสนุนการเปิดตัวสู่ตลาด (4-8 สัปดาห์):
คุณกำลังเปิดตัวในญี่ปุ่น/MENA/EU และต้องการผู้เชี่ยวชาญที่มีประสบการณ์ตรงนี้มาก่อน
ความร่วมมือระยะยาว:
ที่ปรึกษาแบบฝังตัวขณะที่คุณขยายขนาดจาก 2 ภาษาเป็น 20
ไม่ทำทฤษฎี ทำแต่การคัดกรอง แผนงาน และส่งมอบงาน