วิธีแปลไฟล์ PO โดยไม่ทำให้แอปของคุณมีปัญหา

TABLE OF CONTENTS

ไฟล์ PO ดูเหมือนเป็นไฟล์ข้อความธรรมดา จนกว่าการแปล %s ที่ผิด, รูปแบบพหูพจน์ที่ขาดหาย หรือ msgid ที่ถูกแก้ไขจะทำให้แอปของคุณพัง ใช้เวิร์กโฟลว์นี้เพื่อแปลข้อความที่ผู้ใช้เห็น โดยไม่แตะโครงสร้างของ gettext

อย่าแปะไฟล์ทั้งหมดลงในตัวแปลข้อความธรรมดา ไฟล์ PO เป็นเหมือนซอร์สโค้ด: คำต่าง ๆ สามารถแปลได้ แต่โครงสร้างไฟล์, ตัวแทนข้อความ, คอมเมนต์ และดัชนีพหูพจน์ต้องคงเดิม

วิธีที่ 1: ใช้เครื่องมือแปลไฟล์ PO

เลือกวิธีนี้หากคุณต้องการร่างแปลที่รวดเร็วและปลอดภัยที่สุด โดยไม่ต้องแก้ไขคู่ msgid / msgstr ด้วยตนเอง

สำรองไฟล์ .po ต้นฉบับไว้ก่อน เก็บสำเนาที่สะอาดไว้ใน repository ของคุณก่อนส่งให้ผู้แปล หากไฟล์แปลเสียหาย คุณจะได้มีเวอร์ชันที่ใช้งานได้แน่นอนสำหรับเปรียบเทียบ
เปิดด้วยเครื่องมือแปลที่รองรับ PO ใช้เครื่องมือที่สร้างมาเพื่อไฟล์ gettext เช่น OpenL PO Translator ซึ่งเป็นเครื่องมือแปลเอกสารแบบจ่ายตามการใช้งาน เครื่องมือที่รองรับ PO ควรแปลเฉพาะข้อความเป้าหมาย โดยคงข้อความต้นฉบับ, คอมเมนต์, ตัวแทนข้อความ และโครงสร้างไฟล์ไว้ หากคุณยังเลือกเครื่องมืออยู่ สามารถเปรียบเทียบตัวเลือกได้ใน คู่มือเลือกเครื่องมือแปล PO ที่ดีที่สุด
อัปโหลดไฟล์ .po ใช้ไฟล์ภาษาที่มีรายการ msgid และ msgstr หากคุณมีแค่ไฟล์ .pot ให้สร้างไฟล์ .po สำหรับภาษาปลายทางก่อน แล้วจึงอัปโหลดไฟล์ .po
เลือกภาษาต้นทางและปลายทาง ให้ตรงกับข้อความใน msgid ไม่ใช่ภาษาของอินเทอร์เฟซผู้ดูแลระบบ เช่น ถ้าไฟล์มี msgid เป็นภาษาอังกฤษและคุณต้องการผลลัพธ์เป็นภาษาสเปน ให้เลือกแปลจากอังกฤษเป็นสเปน
ดาวน์โหลดไฟล์ที่แปลแล้ว บันทึกโดยใช้รูปแบบชื่อ locale ตามที่เฟรมเวิร์กของคุณต้องการ ปลั๊กอิน WordPress มักใช้รูปแบบ text-domain ตามด้วย locale ส่วน Django มักเก็บไฟล์ไว้ที่ locale/<language>/LC_MESSAGES/
ตรวจสอบสตริงที่มีความเสี่ยงก่อน ค้นหาไฟล์แปลหาคำอย่าง %, {, }, <, >, msgid_plural, msgctxt และ #, fuzzy รายการเหล่านี้มีแนวโน้มจะส่งผลต่อการทำงานของแอปพลิเคชันมากที่สุด
ทดสอบไฟล์แปลในแอปของคุณ โหลดภาษาในเครื่องแล้วคลิกดูหน้าต่างๆ ที่ใช้สตริงที่แปลไว้ ไฟล์ PO จะยังไม่ถือว่าเสร็จสมบูรณ์เมื่อแปลเสร็จ แต่จะเสร็จเมื่อแอปยังแสดงผลได้ถูกต้อง

วิธีที่ 2: แปลไฟล์ PO ด้วย Poedit

เลือกวิธีนี้หากคุณต้องการการตรวจสอบโดยมนุษย์, ความเข้ากันได้กับ WordPress หรือกระบวนการแปลทีละรายการอย่างละเอียด

เปิดไฟล์ใน Poedit Poedit เป็นโปรแกรมแก้ไขไฟล์แปลโดยเฉพาะสำหรับไฟล์ PO และฟอร์แมตอื่นๆ ที่ใช้ในงานโลคัลไลซ์เซชัน ตัวแก้ไขพื้นฐานใช้งานฟรี และมีฟีเจอร์ Pro แบบเสียเงินสำหรับงานที่ซับซ้อนขึ้น สำหรับ WordPress คู่มือ Polyglots อย่างเป็นทางการอธิบายว่า Poedit สามารถสร้างไฟล์ .po และ .mo จากไฟล์ POT ได้ และรองรับรูปแบบพหูพจน์และ UTF-8
อัปเดตจากเทมเพลต POT หากต้นฉบับมีการเปลี่ยนแปลง หากนักพัฒนาเปลี่ยนข้อความในแอป ให้ทำการอัปเดตไฟล์ .po จากไฟล์ .pot ล่าสุดก่อนเริ่มแปล วิธีนี้จะทำให้เห็นสตริงใหม่ สตริงที่ถูกลบ และสตริงที่ไม่แน่ใจ (fuzzy) แทนที่จะปล่อยให้ข้อความ UI เก่าๆ ถูกใช้งานโดยไม่รู้ตัว
แปลเฉพาะฟิลด์ msgstr เท่านั้น msgid คือข้อความต้นฉบับที่แอปใช้ค้นหาคำแปล ในกระบวนการ gettext ปกติ ผู้แปลควรแก้ไขเฉพาะ msgstr ไม่ใช่ msgid
รักษาตัวแปร placeholder ให้เหมือนเดิมทุกประการ ห้ามแปลหรือเปลี่ยนช่องว่างของตัวแปร เช่น %s, %d, %1$s, {name}, %(count)s, :name หรือแท็ก HTML หากจำเป็นต้องเปลี่ยนลำดับคำ ให้ย้าย placeholder ไปทั้งชุด
จัดการรูปแบบพหูพจน์เป็นคำแยกต่างหาก รายการพหูพจน์จะประกอบด้วย msgid, msgid_plural และค่า msgstr[n] หลายค่า ให้กรอกทุกช่องพหูพจน์ที่ภาษาปลายทางต้องการ แทนที่จะคัดลอกประโยคเดียวกันไปทุกช่อง
บันทึกและคอมไพล์ไฟล์ .mo หากแอปของคุณต้องการใช้ สแต็กบางประเภทสามารถอ่านไฟล์ .po ได้โดยตรงระหว่างการพัฒนา แต่ WordPress และระบบที่ใช้ gettext หลายแห่งจะใช้ไฟล์ .mo ที่คอมไพล์แล้วในขณะรันไทม์ Poedit สามารถคอมไพล์ไฟล์ .mo ได้ทันทีเมื่อบันทึก; ส่วน Django สามารถคอมไพล์ข้อความด้วยคำสั่ง django-admin compilemessages
แก้ไขคำเตือนก่อนอัปโหลด ใน Poedit ไอคอนคำเตือนมักจะชี้ไปที่ตัวแปรที่เสีย รูปแบบที่ขาดหาย หรือรูปแบบพหูพจน์ที่ไม่ตรงกัน ควรแก้ไขปัญหาเหล่านี้ก่อนนำเข้าไฟล์แปลไปยัง WordPress, Django, Drupal หรือสาขา release ของคุณ

วิธีที่ 3: ใช้แพลตฟอร์มโลคัลไลเซชัน

เลือกวิธีนี้เมื่อมีนักแปล ผู้ตรวจสอบ หรือผู้จัดการปล่อยเวอร์ชันหลายคนต้องทำงานร่วมกันบนไฟล์ PO เดียวกัน

นำเข้าไฟล์ PO ไปยังแพลตฟอร์มที่รองรับ gettext Weblate และแพลตฟอร์มโลคัลไลเซชันลักษณะเดียวกันรองรับเวิร์กโฟลว์ PO แพลตฟอร์มสำหรับทีมมักเป็นผลิตภัณฑ์ที่ต้องชำระเงิน แม้ว่า Weblate จะมีตัวเลือกโอเพ่นซอร์สสำหรับติดตั้งเองด้วย วิธีจัดการคอมเมนต์ ส่วนหัว สตริง fuzzy และตัวแปร placeholder ของแต่ละแพลตฟอร์มจะแตกต่างกัน ดังนั้นควรตรวจสอบการตั้งค่าฟอร์แมตก่อนอัปโหลดไฟล์สำหรับใช้งานจริง
ตั้งค่าการตรวจสอบ placeholder และแท็ก เปิดใช้งานกฎ QA สำหรับ placeholder แบบ printf ตัวแปรที่มีชื่อ แท็ก HTML/XML และรูปแบบพหูพจน์ การตรวจสอบเหล่านี้จะช่วยจับข้อผิดพลาดที่ตัวตรวจสอบการสะกดปกติไม่สามารถเห็นได้
แสดงคอมเมนต์ของนักพัฒนาให้ชัดเจน คอมเมนต์ในไฟล์ PO สามารถให้บริบท เช่น การอ้างอิงต้นทาง หมายเหตุจากนักพัฒนา ธง และสตริงต้นทางก่อนหน้า นักแปลจำเป็นต้องใช้หมายเหตุเหล่านี้เมื่อป้ายกำกับ UI สั้น ๆ อย่าง “Open” อาจเป็นได้ทั้งคำกริยา คำคุณศัพท์ หรือคำสั่งในเมนู
ใช้หน่วยความจำการแปลร่วมกับการตรวจสอบ Translation memory มีประโยชน์สำหรับสตริง UI ที่ซ้ำกัน แต่บางครั้งอาจคัดลอกคำแปลเก่าไปใช้ในบริบทใหม่ ควรตรวจสอบสตริงที่นำกลับมาใช้ใหม่เมื่อ msgctxt การอ้างอิงต้นทาง หรือ UI รอบข้างมีการเปลี่ยนแปลง
ส่งออกไฟล์ PO และตรวจสอบในเครื่อง อย่าไว้ใจไฟล์ที่ส่งออกมาโดยไม่ตรวจสอบ ให้นำไฟล์แปลกลับเข้าแอป คอมไพล์หากจำเป็น และทดสอบหน้าจอก่อนจะรวมเข้ากับโค้ดหลัก

กฎของไฟล์ PO ที่คุณไม่ควรละเมิด

PO item	แปลหรือไม่?	ตัวอย่างที่ปลอดภัย	ทำไมถึงสำคัญ
`msgid`	ไม่	`msgid "Save changes"`	แอปจะใช้สตริงต้นทางนี้เป็นคีย์สำหรับค้นหาในหลาย ๆ เวิร์กโฟลว์ของ gettext
`msgstr`	ใช่	`msgstr "Guardar cambios"`	นี่คือตัวข้อความภาษาปลายทางที่ผู้ใช้จะเห็น
`msgctxt`	ไม่	`msgctxt "button"`	คอนเท็กซ์ช่วยแยกความหมายของสตริงต้นทางที่เหมือนกัน
`%s`, `%d`, `%1$s`	ไม่	`Hello, %s` -> `Hola, %s`	โค้ดขณะรันจะแทนที่ตัวแปรเหล่านี้ด้วยค่าจริง
`{name}`, `%(count)s`, `:name`	ไม่	`Welcome, {name}`	ตัวแปรที่มีชื่อเหล่านี้ต้องตรงกับโค้ดของแอปเสมอ
HTML tags	โดยปกติไม่	`<strong>Warning</strong>`	แปลเฉพาะข้อความ ไม่ใช่ไวยากรณ์แท็ก
`msgid_plural`	ไม่	`msgid_plural "%d files"`	รูปพหูพจน์ต้นทางเป็นของเส้นทางโค้ดต้นฉบับ
`msgstr[0]`, `msgstr[1]`	ใช่ แต่ต้องระวัง	`msgstr[0] "%d file"`	แต่ละภาษามีกฎพหูพจน์ของตัวเอง
`#, fuzzy`	ตรวจสอบก่อน	`#, fuzzy`	fuzzy หมายถึงการแปลอาจล้าสมัยหรือยังไม่ได้ยืนยัน
`#.` developer comments	โดยปกติไม่	`#. Button label`	หมายเหตุเหล่านี้ช่วยให้ผู้แปลเข้าใจบริบท

ตัวอย่างเร็ว: การแปล PO ที่ปลอดภัยกับที่ผิดพลาด

นี่คือตัวอย่าง entry ของ gettext ปกติ:

#. %s is the user's display name.
#, c-format
msgid "Welcome back, %s"
msgstr ""

การแปลเป็นภาษาสเปนที่ถูกต้องจะคง %s ไว้เหมือนเดิม:

#. %s is the user's display name.
#, c-format
msgid "Welcome back, %s"
msgstr "Bienvenido de nuevo, %s"

การแปลที่ผิดจะเปลี่ยนตัวแปร placeholder:

msgid "Welcome back, %s"
msgstr "Bienvenido de nuevo, % s"

ช่องว่างเล็ก ๆ ตรงนั้นอาจมีผลสำคัญ GNU msgfmt --check-format ถูกออกแบบมาเพื่อตรวจจับความไม่ตรงกันของฟอร์แมตสตริง เช่น placeholder % ที่ผิด และ Poedit ก็จะแจ้งเตือนปัญหา placeholder ทั่วไปด้วย สำหรับรายการสตริงที่ควรปล่อยไว้ไม่ต้องแปลเพิ่มเติม ดูคู่มือของเราได้ที่ สิ่งที่ไม่ควรแปล

วิธีตรวจสอบไฟล์ PO ที่แปลแล้ว

ตรวจสอบความถูกต้องของไฟล์ gettext หากคุณติดตั้ง gettext แล้ว

msgfmt --check --check-format -o /tmp/messages.mo path/to/messages.po

คำสั่งนี้จะตรวจสอบไวยากรณ์ ส่วนหัว และรูปแบบสตริง จากนั้นจะสร้างไฟล์ catalog ชั่วคราวหากไฟล์นั้นถูกต้อง

คอมไพล์ไฟล์ตามวิธีที่เฟรมเวิร์กของคุณต้องการ

django-admin compilemessages

สำหรับโปรเจกต์ Django คำสั่ง compilemessages จะคอมไพล์ไฟล์ .po ที่สร้างโดย makemessages ให้เป็นไฟล์ .mo เพื่อรองรับ gettext

ค้นหาข้อความแปลที่ว่างเปล่า

grep -n 'msgstr ""' path/to/messages.po

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

ค้นหาข้อความ fuzzy

grep -n '#, fuzzy' path/to/messages.po

ข้อความ fuzzy ควรได้รับการตรวจสอบโดยมนุษย์ก่อนปล่อยใช้งาน โดยปกติ msgfmt จะไม่ใช้ข้อความ fuzzy เว้นแต่คุณจะคอมไพล์ด้วย --use-fuzzy ดังนั้นข้อความ fuzzy จะทำงานเหมือนข้อความที่ยังไม่ได้แปลใน catalog สุดท้าย

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

ควรใช้วิธีไหน?

สถานการณ์	วิธีที่ดีที่สุด	เหตุผล
คุณต้องการร่างแปลแรกอย่างรวดเร็วสำหรับไฟล์ PO หนึ่งไฟล์	ตัวแปลไฟล์ PO	เส้นทางที่เร็วที่สุดพร้อมคงโครงสร้างเดิมไว้
คุณดูแลปลั๊กอินหรือธีม WordPress	Poedit	เวิร์กโฟลว์ที่คุ้นเคยกับ WordPress พร้อมการคอมไพล์ `.mo`
คุณดูแลแอป Django	ตัวแปล PO หรือ Poedit แล้วใช้ `compilemessages`	การแปลสามารถทำได้รวดเร็ว แต่ยังต้องคอมไพล์ด้วยเฟรมเวิร์กอยู่ดี
คุณมีหลายภาษาและผู้ตรวจสอบหลายคน	แพลตฟอร์มโลคัลไลเซชัน	การมอบหมายงาน ประวัติการแปล การควบคุมคุณภาพ และการตรวจสอบดีกว่า
คุณกำลังแปลข้อความสำหรับนักพัฒนา	ตรวจสอบโดยมนุษย์หลังจากแปลด้วยเครื่อง	คำศัพท์โค้ด ตัวแปร และบริบทมีความสำคัญมากกว่า
คุณต้องโลคัลไลซ์ไฟล์ JSON หรือไฟล์ i18n ฝั่งหน้าเว็บด้วย	ใช้เวิร์กโฟลว์เฉพาะรูปแบบไฟล์	กฎของ PO ไม่ได้ใช้กับ JSON, YAML หรือข้อความ ICU เสมอไป

หากโปรเจกต์ของคุณผสมไฟล์ gettext PO กับไฟล์ locale แบบ JSON ให้แปลแต่ละรูปแบบด้วยเครื่องมือที่เข้าใจโครงสร้างของไฟล์นั้น ๆ ไฟล์ PO จะเน้นที่ msgid และ msgstr ส่วนการโลคัลไลซ์ JSON จะเน้นที่ key และ value สำหรับเวิร์กโฟลว์นี้ ดูคู่มือของเราเกี่ยวกับ ตัวแปล JSON ที่ดีที่สุดในปี 2026

คำถามที่พบบ่อย

ฉันสามารถแปลไฟล์ PO ด้วย Google Translate ได้ไหม?

คุณสามารถคัดลอกค่า msgstr ทีละบรรทัดไปแปลในตัวแปลทั่วไปได้ แต่การอัปโหลดหรือวางไฟล์ PO ทั้งไฟล์ลงในตัวแปลข้อความธรรมดานั้นเสี่ยงมาก ตัวแปลทั่วไปอาจเปลี่ยนแปลง msgid คำอธิบาย การหนีเครื่องหมายคำพูด ดัชนีพหูพจน์ หรือ placeholder ได้ ควรใช้ตัวแปลที่รองรับไฟล์ PO, Poedit หรือแพลตฟอร์มโลคัลไลเซชันแทน

ความแตกต่างระหว่าง `.po`, `.pot` และ `.mo` คืออะไร?

.pot คือไฟล์แม่แบบที่สกัดมาจากซอร์สโค้ด โดยปกติจะมีแต่ข้อความต้นฉบับโดยไม่มีคำแปล .po คือไฟล์แปลที่แก้ไขได้สำหรับแต่ละภาษาเป้าหมาย ส่วน .mo คือไฟล์ไบนารีที่คอมไพล์แล้ว ซึ่งแอปที่ใช้ gettext ส่วนใหญ่จะโหลดขณะรันไทม์

ควรแปล `msgid` หรือไม่?

ไม่, ไม่อยู่ในขั้นตอนการทำงานปกติ ให้แปลเฉพาะ msgstr เท่านั้น คู่มือ GNU gettext อธิบายว่า msgid คือสตริงต้นฉบับที่ยังไม่ได้แปล และ msgstr คือสตริงที่แปลแล้ว; สตริง msgid จะถูกสร้างและจัดการโดยเครื่องมือของ gettext

จะตรวจสอบได้อย่างไรว่าไฟล์ PO ถูกต้องหรือไม่?

ให้รันคำสั่ง msgfmt --check --check-format หากมี gettext อยู่ในเครื่อง, เปิดไฟล์ใน Poedit หรือใช้ระบบตรวจสอบคุณภาพของแพลตฟอร์มโลคัลไลเซชันของคุณ จากนั้นคอมไพล์และทดสอบไฟล์ในแอป การตรวจสอบความถูกต้องเป็นสิ่งจำเป็น แต่ไม่สามารถทดแทนการทดสอบบน UI ได้

จะเกิดอะไรขึ้นถ้าฉันทำให้ placeholder ผิดพลาด?

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

OpenL สามารถแปลไฟล์ PO ได้หรือไม่?

ได้ OpenL PO Translator ถูกออกแบบมาสำหรับไฟล์ gettext .po และระบุว่าจะคง placeholder และตัวแปรไว้โดยไม่เปลี่ยนแปลงขณะทำการแปลมากกว่า 100 ภาษา ใช้ระบบแปลเอกสารแบบจ่ายตามการใช้งาน เหมาะสำหรับร่างแปลฉบับแรกอย่างรวดเร็วเมื่อโครงสร้าง PO สำคัญกว่าการแปลด้วยมือทั้งหมด หากคุณมีเพียงไฟล์ .pot ให้สร้างไฟล์ .po สำหรับภาษาปลายทางก่อนใช้งาน OpenL

แหล่งข้อมูล

คู่มือ GNU gettext: ไฟล์ PO — คำอธิบายอย่างเป็นทางการของรูปแบบไฟล์ PO จาก gettext
คู่มือ GNU gettext: รายการในไฟล์ PO — แหล่งข้อมูลสำหรับ msgid, msgstr, คำอธิบาย, ธง และโครงสร้างของแต่ละรายการ
คู่มือ GNU gettext: รายการที่มีรูปแบบพหูพจน์ — แหล่งข้อมูลเกี่ยวกับโครงสร้างของรายการแบบพหูพจน์
คู่มือ GNU gettext: การเรียกใช้ msgfmt — แหล่งข้อมูลสำหรับ msgfmt --check และการตรวจสอบรูปแบบสตริง
OpenL PO Translator — หน้าผลิตภัณฑ์ OpenL สำหรับแปลไฟล์ .po โดยรักษาตัวแปรและ placeholder ไว้
Poedit — เว็บไซต์อย่างเป็นทางการของ Poedit สำหรับโปรแกรมแก้ไขไฟล์ PO และเวอร์ชัน Pro
WordPress Polyglots Handbook: Poedit — คู่มือจาก WordPress สำหรับการใช้ Poedit, ไฟล์ POT, ไฟล์ PO, การคอมไพล์ MO และคำเตือนเกี่ยวกับ placeholder
เอกสาร Django: การแปลภาษา — ขั้นตอนการทำงานกับไฟล์ข้อความและการแปลใน Django
เอกสาร Django: compilemessages — อ้างอิงคำสั่ง Django สำหรับคอมไพล์ไฟล์ .po เป็นไฟล์ .mo
เอกสาร Drupal: ไฟล์ PO และ POT — คำอธิบายของ Drupal เกี่ยวกับไฟล์ .po, .pot, บริบท, รูปแบบพหูพจน์, คำอธิบาย และตัวแปร
เอกสาร Weblate: GNU gettext PO — หมายเหตุเกี่ยวกับแพลตฟอร์มโลคัลไลเซชันเกี่ยวกับส่วนหัวของ PO, สตริงต้นฉบับก่อนหน้า, สตริงที่เลิกใช้แล้ว และไฟล์ MO ที่สร้างขึ้น