วิธีแปลไฟล์ XLIFF (Drupal, Symfony, Angular, iOS)

เมื่อสัปดาห์ที่แล้ว นักพัฒนา Drupal คนหนึ่งได้โพสต์เรื่องราวลงบน Stack Overflow ซึ่งเป็นเหตุการณ์ที่เกิดขึ้นซ้ำๆ หลายพันครั้งต่อปีในทีมแปลภาษาขององค์กร ทีมของเธอส่งออกไฟล์ XLIFF ขนาด 40MB จากเว็บไซต์ Drupal เธอเปิดไฟล์นั้นในโปรแกรมแก้ไขข้อความ คัดลอกส่วนต่างๆ ไปวางใน Google Translate ประกอบไฟล์ใหม่ แล้วนำเข้ากลับไปยัง Drupal – ปรากฏว่าครึ่งหนึ่งของหน้าเว็บไม่แสดงผล เนื่องจากสตริงที่แปลแล้วมี XML ที่ผิดรูปแบบ อักขระหลีกผิดตำแหน่ง และแท็ก <g> ที่เสียหายซึ่งทำให้การจัดรูปแบบแบบอินไลน์ถูกทำลาย

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

คู่มือนี้จะอธิบายถึงสิ่งที่ทำให้ XLIFF แตกต่าง ทำไมวิธีการแปลแบบทั่วไปถึงทำให้มันเสียหายได้ และวิธีที่ถูกต้องในการแปลไฟล์ XLIFF สำหรับ Drupal, Symfony, Angular และ iOS ซึ่งเป็นสี่แพลตฟอร์มที่ใช้ XLIFF บ่อยที่สุดในปี 2026

XLIFF คืออะไร (และทำไมทีมองค์กรถึงใช้มัน)

XLIFF ย่อมาจาก XML Localization Interchange File Format เป็นมาตรฐานของ OASIS ที่ออกแบบมาโดยเฉพาะสำหรับการถ่ายโอนเนื้อหาการแปลระหว่างเครื่องมือต่างๆ เช่น ระบบจัดการเนื้อหา, ฐานข้อมูลหน่วยความจำการแปล, เครื่องมือ CAT และแพลตฟอร์มการแปล ซึ่งแตกต่างจากไฟล์ Gettext .po (ที่เก็บคู่คีย์-ค่าแบบเรียบ) หรือไฟล์ภาษา JSON (ที่มีการซ้อนกันแบบไม่จำกัด) XLIFF เป็นเอกสาร XML ที่มีโครงสร้างและมี schema ที่ได้มาตรฐาน

XLIFF 1.2 vs XLIFF 2.0

มีสองเวอร์ชันที่ใช้งานอยู่จริง และไม่สามารถเข้ากันได้อย่างสมบูรณ์

XLIFF 1.2 เป็นเวอร์ชันเก่ากว่าและใช้งานแพร่หลายกว่า ใช้ส่วนประกอบ <trans-unit> เพื่อห่อหุ้มเนื้อหาที่แปลได้ โดยมี <source> และ <target> เป็นลูกหลาน การจัดรูปแบบแบบอินไลน์ใช้แท็กคู่ <g>, <x> และ <bpt> / <ept> เครื่องมือ Translation Management Tool ของ Drupal และแพลตฟอร์มเก่าๆ จำนวนมากยังคงส่งออกเวอร์ชัน 1.2

XLIFF 2.0 คือการปรับปรุงในปี 2014 ที่เรียบง่ายและสะอาดตาขึ้น ใช้ <unit> และ <segment> โดยมี <source> และ <target> การมาร์กอัปแบบอินไลน์ใช้ <pc> (paired code) และ <ph> (placeholder) ส่วนประกอบตัวแปลของ Symfony และการส่งออกของ iOS สมัยใหม่จะใช้เวอร์ชัน 2.0 เป็นค่าเริ่มต้น

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

กายวิภาคของ XLIFF Unit

XLIFF 1.2 trans-unit แบบเรียบง่ายมีลักษณะดังนี้:

<trans-unit id="msg_welcome" datatype="plaintext">
  <source>Welcome, <g id="1">%name%</g>!</source>
  <target state="needs-translation">Welcome, <g id="1">%name%</g>!</target>
  <note>Displayed on the homepage after login</note>
</trans-unit>

<g id="1"> ครอบตัวแปร placeholder คุณลักษณะ state บอกแพลตฟอร์มว่าสตริงนี้ต้องการการแปล ส่วน <note> เป็นคำแนะนำสำหรับนักพัฒนา นักแปลที่เข้าใจ XLIFF ควรสร้างผลลัพธ์ดังนี้:

<target state="translated">¡Bienvenido, <g id="1">%name%</g>!</target>

นักแปลที่ถือว่าไฟล์เป็นข้อความธรรมดาอาจสร้างผลลัพธ์ที่เสียหายดังต่อไปนี้:

<target>¡Bienvenido, <g id="1">%nombre%</g>!</target>
<target>¡Bienvenido, &lt;g id="1"&gt;%name%&lt;/g&gt;!</target>
<target>¡Bienvenido, %name%!</target>

แต่ละวิธีเหล่านี้ทำให้การนำเข้าเสียหายแตกต่างกันไป แบบแรกเปลี่ยนชื่อตัวแปร แบบที่สองหลีกเลี่ยง XML แบบที่สามละทิ้งแท็กการจัดรูปแบบไปเลย

วิธีแก้ปัญหาที่ไม่ดี (ทำไมคุณถึงไม่สามารถแปล XML ได้โดยตรง)

ทีมส่วนใหญ่เริ่มต้นด้วยสามวิธีเดียวกันนี้ และเสียเวลาไปหลายวันก่อนที่จะยอมแพ้

ส่ง XLIFF ให้ AI ทั่วไป

คัดลอกไฟล์ วางลงใน Claude หรือ ChatGPT แล้วขอให้แปล โดยปกติแล้วโมเดลจะแปลข้อความได้ดีพอสมควร แต่จะจัดการกับแท็ก XLIFF อย่างไม่สอดคล้องกัน บางครั้งก็รักษาแท็ก <g> ไว้ บางครั้งก็แปลคุณลักษณะ id บางครั้งก็ลบทิ้งไปเลย การตรวจสอบความถูกต้องล้มเหลว การนำเข้าของคุณจะเกิดข้อผิดพลาดในการแยกวิเคราะห์ XML

การใช้ CAT Tool ที่ไม่รองรับ XLIFF

เครื่องมืออย่าง Poedit ถูกสร้างมาสำหรับรูปแบบ .po มันอาจเปิดไฟล์ XLIFF ได้ แต่จะถือว่าเป็นคอนเทนเนอร์ข้อความทั่วไป แท็กแบบอินไลน์จะไม่ถูกล็อค Placeholders จะไม่ได้รับการป้องกัน คุณจะได้การแปลที่ดูดีในตัวแก้ไข แต่ล้มเหลวในการตรวจสอบความถูกต้องของ schema เมื่อนำเข้า

การเขียนสคริปต์แบบกำหนดเอง

ทีมของคุณเขียนสคริปต์ Node หรือ Python ที่แยกวิเคราะห์ XLIFF ด้วย xml2js ดึงสตริงต้นฉบับ เรียก Google Translate และเขียนเป้าหมายกลับไป มันทำงานได้กับ 90% ของสตริง ส่วนอีก 10% – สตริงที่มีการจัดรูปแบบที่ซ้อนกัน กลุ่มพหูพจน์ หรืออักขระพิเศษ – จะเสียหายในลักษณะที่แสดงออกมาหลังจากที่คุณได้เผยแพร่ไปแล้วเท่านั้น

โหมดความล้มเหลวแบบเดียวกันที่เรียกว่า "รูปแบบยืดหยุ่นพบกับนักแปลที่ไร้เดียงสา" นี้ส่งผลกระทบต่อไฟล์ i18next JSON และ Gettext .po คู่มือของเราเกี่ยวกับการ แปลไฟล์ i18next JSON สำหรับ React และ Next.js และโพสต์ของเราเกี่ยวกับ วิธีแปลไฟล์ .po โดยไม่ทำลายตัวแปรโค้ด ครอบคลุมปัญหาคู่ขนานสำหรับรูปแบบเหล่านั้น

วิธีที่ถูกต้อง: การประมวลผล XLIFF ที่คำนึงถึงไวยากรณ์

กระบวนการแปล XLIFF ที่เหมาะสมจะปฏิบัติตามหลักการเดียวกับเอ็นจิ้น PO ของเรา ซึ่งปรับให้เข้ากับ XML

แยกวิเคราะห์ ไม่ใช่ Regex

ปฏิบัติต่อ XLIFF ในฐานะเอกสารที่มีโครงสร้าง แยกวิเคราะห์ด้วยตัวแยกวิเคราะห์ XML จริง สร้างโครงสร้างต้นไม้ และเดินผ่านองค์ประกอบ <trans-unit> (หรือ <unit> สำหรับเวอร์ชัน 2.0) การพยายามใช้ regex เพื่อจับคู่เนื้อหาต้นฉบับและเป้าหมายเป็นวิธีที่รวดเร็วในการทำให้ไฟล์เสียหาย

ล็อคแท็กอินไลน์ก่อนการแปล

แท็ก <g>, <x>, <bpt>, <ept>, <ph>, <pc> ทุกแท็กที่อยู่ใน <source> จะต้องถูกรักษาไว้ตามตำแหน่งและคุณลักษณะ id แทนที่แท็กเหล่านี้ด้วย numeric placeholders ก่อนส่งข้อความไปยังโมเดลภาษาขนาดใหญ่ จากนั้นจึงแทรกแท็กดั้งเดิมพร้อมคุณลักษณะกลับเข้าไปใหม่หลังจากได้ข้อความที่แปลแล้ว

เคารพสถานะการทำงาน

หน่วย XLIFF มีคุณลักษณะสถานะ: new, needs-translation, translated, reviewed, final, signed-off กระบวนการควรแปลเฉพาะหน่วยที่อยู่ในสถานะ new หรือ needs-translation และตั้งค่าสถานะผลลัพธ์เป็น translated (ไม่ใช่ final – ผู้ตรวจสอบควรยังคงตรวจสอบ)

รักษาสภาพโครงสร้างให้คงอยู่มากกว่าแค่หน่วยการแปล

ไฟล์ XLIFF มีส่วนหัว, เมตาดาต้า, คุณลักษณะระดับไฟล์, บันทึก และการแปลทางเลือก (<alt-trans>) สิ่งเหล่านี้จะต้องคงอยู่ไม่เปลี่ยนแปลงตลอดการส่งและรับ การลบหรือจัดเรียงใหม่จะทำให้ความเข้ากันได้กับการส่งและรับกับแพลตฟอร์มต้นทางเสียหาย

ตรวจสอบความถูกต้องก่อนส่งมอบ

ก่อนที่จะส่งคืน XLIFF ที่แปลแล้ว ให้ตรวจสอบความถูกต้องตาม schema XLIFF 1.2 มี XSD อย่างเป็นทางการ XLIFF 2.0 ก็มีของตัวเอง เครื่องมือที่ไม่สามารถตรวจสอบความถูกต้องเองได้คือเครื่องมือที่จะส่งไฟล์ที่เสียหายมาให้คุณ

ข้อสังเกตเฉพาะแพลตฟอร์ม

แต่ละแพลตฟอร์มหลักที่ใช้ XLIFF มีลักษณะเฉพาะที่ควรทราบ

Drupal

Translation Management Tool (TMGMT) ของ Drupal ส่งออก XLIFF 1.2 ประเภทเนื้อหาประกอบด้วย nodes (หน้า, บทความ), taxonomy terms และการตั้งค่า TMGMT ห่อหุ้มแต่ละฟิลด์ที่แปลได้ใน <trans-unit> แยกกัน พร้อมรูปแบบ ID เฉพาะของ Drupal (fieldname:delta:format)

ข้อควรระวัง: Drupal จัดเก็บข้อมูลรูปแบบข้อความ (filtered HTML, full HTML, plain text) พร้อมกับเนื้อหา การแปลจะต้องรักษาการมาร์กอัป HTML เมื่อรูปแบบอนุญาต และลบเหลือเพียงข้อความธรรมดาเมื่อรูปแบบไม่อนุญาต กระบวนการของคุณจำเป็นต้องรับรู้ข้อมูลแต่ละฟิลด์

Symfony

ส่วนประกอบการแปลของ Symfony ใช้ XLIFF 2.0 โดยค่าเริ่มต้น (ตั้งแต่ Symfony 4) สตริงจะอยู่ใน translations/messages.xx.xliff Symfony รองรับรูปแบบข้อความ ICU ภายใน XLIFF ซึ่งหมายความว่าหน่วยเดียวสามารถมีโครงสร้าง {count, plural, one {...} other {...}} ได้

ข้อควรระวัง: หมวดหมู่พหูพจน์ของ ICU ภายใน XLIFF จำเป็นต้องมีการป้องกันสองชั้น แท็ก XML ต้องคงอยู่ และคำสำคัญของ ICU (plural, one, other, =0) จะต้องไม่ถูกแปล เครื่องมือ XLIFF หลายตัวจัดการได้เพียงชั้นเดียว แต่ไม่ใช่ทั้งสองชั้น

Angular i18n

Angular ส่งออก XLIFF 1.2 หรือ 2.0 ผ่านคำสั่ง ng extract-i18n ไฟล์ประกอบด้วยสตริงเทมเพลตส่วนประกอบ พร้อมแท็ก <x> ที่แสดงถึงนิพจน์และการสอดแทรกของ Angular เช่น {{ count }}

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

iOS (Xcode Export)

Xcode ส่งออก XLIFF 1.2 สำหรับการแปลแอปผ่าน Product > Export Localizations สตริงมาจาก Localizable.strings, รายการ Info.plist, storyboards และ XIBs กฎพหูพจน์ของ iOS จะอยู่ในไฟล์ .stringsdict ที่ส่งออกเป็น trans-unit เพิ่มเติม

ข้อควรระวัง: สตริง storyboard ของ iOS อ้างอิง ID ขององค์ประกอบ UI สิ่งเหล่านี้จะต้องไม่ถูกแก้ไข นอกจากนี้ Xcode ต้องการให้คุณลักษณะ target-language ตรงกับรูปแบบ locale ที่คาดไว้ (es ไม่ใช่ es-ES ในบางบริบท) อย่างสมบูรณ์ มิฉะนั้นจะละเว้นการนำเข้าโดยไม่มีการแจ้งเตือน

การแปล XLIFF ด้วย SimplePoTranslate

SimplePoTranslate รองรับ XLIFF ในแพ็คเกจ Pro และ Lifetime ขั้นตอนการทำงานเหมือนกับไฟล์ .po

1. ส่งออก XLIFF ของคุณ

จากแพลตฟอร์มต้นฉบับของคุณ ให้ส่งออกไฟล์ .xliff หนึ่งไฟล์หรือมากกว่า สำหรับ Drupal ให้ใช้การส่งออกของ TMGMT สำหรับ Symfony ให้หา translations/messages.en.xliff สำหรับ Angular ให้รัน ng extract-i18n --format=xlf2 สำหรับ Xcode ให้ใช้การส่งออก Localization

2. อัปโหลดไปยัง SimplePoTranslate

ลากไฟล์ลงในแดชบอร์ด แพลตฟอร์มจะตรวจจับเวอร์ชัน XLIFF โดยอัตโนมัติ (1.2 หรือ 2.0) แยกวิเคราะห์โครงสร้าง และระบุหน่วยที่แปลได้ เลือกภาษาเป้าหมายและโทนเสียงของคุณ

3. การแปลที่คำนึงถึงไวยากรณ์

แท็กอินไลน์, พารามิเตอร์ ICU, placeholders และ ID ของหน่วยจะถูกล็อคก่อนการแปล เอ็นจิ้น AI ที่อยู่เบื้องหลังจะเห็นเพียงข้อความที่สะอาดพร้อมบริบท ข้อความที่แปลแล้วจะถูกแทรกกลับเข้าไปในโครงสร้างดั้งเดิมที่ถูกต้อง สถานะจะได้รับการอัปเดต และไฟล์จะได้รับการตรวจสอบความถูกต้องตาม XLIFF schema ก่อนส่งมอบ

4. ดาวน์โหลดและนำเข้า

ดาวน์โหลด XLIFF ที่แปลแล้ว (รวมถึงไฟล์ .po, .json และ .php ที่เทียบเท่ากันหากคุณต้องการใช้งานข้ามแพลตฟอร์ม) นำเข้าไปยังแพลตฟอร์มต้นฉบับของคุณ ตรวจสอบความถูกต้องโดยการแสดงผลหน้าเว็บหรือมุมมองที่แปลแล้วสองสามหน้าก่อนที่จะนำไปใช้งานจริง

# Angular example
ng extract-i18n --format=xlf2 --output-path=src/locale
# upload src/locale/messages.xlf to SimplePoTranslate
# download messages.es.xlf
# reference in angular.json i18n configuration
ng build --localize

5. รวมเข้ากับ CI

เมื่อคุณเชื่อมั่นในกระบวนการแล้ว ให้ทำให้เป็นอัตโนมัติ ส่งออก XLIFF ทุกครั้งที่ออกเวอร์ชันใหม่ ส่งผ่าน API ดาวน์โหลดไฟล์ที่แปลแล้ว commit ไปยัง repo และ deploy นี่คือรูปแบบที่รองรับ CI เดียวกันกับที่เอเจนซีหลายแห่งใช้สำหรับการแปลไฟล์ .po ของ WordPress – ดูโพสต์ของเราเกี่ยวกับ การแปลบนคลาวด์โดยไม่ทำให้เว็บไซต์เสียหาย สำหรับรูปแบบสถาปัตยกรรม

สรุปทั้งหมด

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

แนวทางที่ปลอดภัยคือการรับรู้ไวยากรณ์: แยกวิเคราะห์ XML, ล็อคองค์ประกอบโครงสร้าง, แปลเฉพาะส่วนของข้อความพร้อมบริบท, ตรวจสอบความถูกต้องตาม schema ก่อนส่งมอบ นี่เป็นจริงไม่ว่าคุณจะเผยแพร่เว็บไซต์ Drupal, Symfony API, Angular SPA หรือแอป iOS แพลตฟอร์มอาจแตกต่างกันไป แต่หลักการของ XLIFF ไม่ได้แตกต่าง

พร้อมที่จะแปลไฟล์ XLIFF สำหรับ Drupal, Symfony, Angular หรือ iOS โดยไม่มีแท็กเสียหายแล้วหรือยัง? ลองใช้ SimplePoTranslate ฟรี – ไม่ต้องใช้บัตรเครดิต อัปโหลด .xliff ดาวน์โหลดคำแปลที่ปลอดภัย และนำเข้าสู่แพลตฟอร์มของคุณ