วิธีคอมไพล์ไฟล์ .po เป็น .mo (4 วิธี)

คุณใช้เวลาช่วงบ่ายเพื่อปรับปรุงการแปลภาษาเยอรมันให้สมบูรณ์แบบ ทุกสตริงในไฟล์ de_DE.po ของคุณอ่านได้อย่างสวยงาม ตัวยึดตำแหน่ง (placeholders) ไม่เสียหาย รูปแบบพหูพจน์ถูกต้อง คุณอัปโหลดไปยังเว็บไซต์ของคุณ เปลี่ยนภาษาเป็นเยอรมัน และ... ไม่มีอะไรเกิดขึ้น หน้าเว็บยังคงเป็นภาษาอังกฤษ คุณตรวจสอบชื่อไฟล์ โฟลเดอร์ และ text domain อีกครั้ง ทุกอย่างดูเหมือนถูกต้อง แล้วทำไม WordPress ถึงไม่แสดงการแปลของคุณ?

เก้าในสิบครั้ง คำตอบเหมือนกัน: คุณแก้ไขไฟล์ .po แต่ไม่เคยคอมไพล์เป็น .mo WordPress ไม่อ่านไฟล์ .po ในขณะรันไทม์ — แต่จะโหลดไฟล์ไบนารี .mo ที่คอมไพล์แล้ว หากคุณต้องการให้การแปลของคุณปรากฏขึ้นจริง คุณต้องคอมไพล์ .po เป็น .mo ทุกครั้งที่คุณเปลี่ยนข้อความ ไฟล์ .po คือต้นฉบับที่คุณแก้ไขได้ ไฟล์ .mo คือสิ่งที่เว็บไซต์ให้บริการ

คู่มือนี้จะอธิบายว่าทำไมขั้นตอนการคอมไพล์นี้จึงมีอยู่ จากนั้นจะแนะนำสี่วิธีที่เชื่อถือได้ในการดำเนินการ: WP-CLI, คำสั่งคลาสสิก msgfmt, Poedit และเครื่องมือคลาวด์ที่สร้างไฟล์ .mo ให้คุณโดยอัตโนมัติ เราจะกล่าวถึงข้อผิดพลาดที่พบบ่อยที่สุด — การลืมคอมไพล์ใหม่ — และรูปแบบ .l10n.php ใหม่ที่ WordPress ชื่นชอบเพื่อความรวดเร็ว

ทำไม WordPress ถึงโหลดไฟล์ .mo และไม่ใช่ .po?

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

ไฟล์ .po เป็นไฟล์ที่อิงตามบรรทัดและเป็นมิตรกับมนุษย์ แต่ละรายการจะจับคู่ msgid ต้นฉบับกับการแปล msgstr พร้อมด้วยความคิดเห็นที่ระบุที่มาของสตริง ซึ่งยอดเยี่ยมสำหรับการแก้ไข แต่แย่มากสำหรับประสิทธิภาพ — เซิร์ฟเวอร์จะต้องแยกวิเคราะห์ไฟล์ข้อความทั้งหมดใหม่ทุกคำขอ

#: includes/cart.php:88
msgid "Your cart is empty"
msgstr "Ihr Warenkorb ist leer"

ไฟล์ .mo จะบรรจุคู่สตริงเดียวกันเหล่านั้นให้อยู่ในรูปแบบไบนารีพร้อมตารางค้นหาภายใน ดังนั้น WordPress จึงสามารถข้ามไปที่การแปลได้โดยตรงโดยไม่ต้องสแกนข้อความ ข้อเสียคือไฟล์ .mo ไม่สามารถอ่านได้โดยมนุษย์ และต้องสร้างใหม่ทุกครั้งที่ไฟล์ .po เปลี่ยนแปลง หากความแตกต่างระหว่าง .po กับ .mo ยังไม่ชัดเจน บทความอธิบายของเราเกี่ยวกับ .po vs .mo vs .pot files จะอธิบายแต่ละรูปแบบและความสัมพันธ์ของพวกมัน

สี่วิธีในการคอมไพล์ .po เป็น .mo

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

วิธีที่ 1: WP-CLI

แนวทางที่ทันสมัยที่สุดคือ WP-CLI ซึ่งสามารถคอมไพล์โฟลเดอร์ .po ทั้งหมดได้ในคำสั่งเดียว หากคุณจัดการ WordPress จากบรรทัดคำสั่งอยู่แล้ว วิธีนี้จะเข้ากับเวิร์กโฟลว์ของคุณได้อย่างเป็นธรรมชาติ

# Compile every .po file in the languages folder to .mo
wp i18n make-mo languages/

# Compile into a specific destination directory
wp i18n make-mo languages/ build/languages/

คำสั่ง make-mo จะสแกนไดเรกทอรีเป้าหมาย คอมไพล์ไฟล์ .po แต่ละไฟล์ที่พบ และเขียนไฟล์ .mo ที่ตรงกันไว้ข้างๆ (หรือไปยังปลายทางที่คุณระบุ) มันจัดการชุดข้อมูลได้อย่างราบรื่น ซึ่งทำให้เหมาะเมื่อคุณดูแลหลายภาษาพร้อมกัน เป็นเครื่องมือที่แนะนำสำหรับทุกโครงการที่ใช้ WP-CLI อยู่แล้ว

วิธีที่ 2: msgfmt

ยูทิลิตี Gettext ดั้งเดิมสำหรับงานนี้คือ msgfmt ซึ่งเป็นส่วนหนึ่งของแพ็คเกจ GNU gettext มันคอมไพล์ไฟล์ .po เดียวเป็นไฟล์ .mo เดียว และมีให้ใช้งานบนระบบ Linux และ macOS เกือบทุกระบบ

# Compile one file
msgfmt my-plugin-de_DE.po -o my-plugin-de_DE.mo

# Add statistics about translated, fuzzy, and untranslated strings
msgfmt --statistics my-plugin-de_DE.po -o my-plugin-de_DE.mo

# Install it first if missing
#   macOS:  brew install gettext
#   Debian: sudo apt-get install gettext

แฟล็ก -o จะระบุชื่อไฟล์เอาต์พุต แฟล็ก --statistics มีประโยชน์อย่างแท้จริง — มันจะบอกคุณว่ามีสตริงที่แปลแล้ว, คลุมเครือ (fuzzy) หรือยังว่างเปล่ากี่สตริง ดังนั้นคุณจึงสามารถตรวจพบการแปลที่ไม่สมบูรณ์ก่อนที่จะนำไปใช้งานจริง สำหรับการสคริปต์ทีละไฟล์ msgfmt เป็นตัวเลือกที่เชื่อถือได้และไม่มีสิ่งฟุ่มเฟือย

เนื่องจาก msgfmt เป็นเครื่องมือบรรทัดคำสั่งธรรมดา จึงสามารถรวมเข้ากับการทำงานอัตโนมัติได้อย่างลงตัว คุณสามารถใส่ไว้ใน shell loop เพื่อคอมไพล์โฟลเดอร์ทั้งหมด หรือเชื่อมโยงเข้ากับ CI pipeline เพื่อให้ทุกคอมมิตที่เกี่ยวข้องกับ .po สร้าง .mo ใหม่โดยอัตโนมัติ รูปแบบทั่วไปคือ for f in languages/*.po; do msgfmt "$f" -o "${f%.po}.mo"; done ซึ่งคอมไพล์ทุกภาษาในครั้งเดียว แฟล็ก --check เพิ่มการตรวจสอบความถูกต้อง โดยจะตั้งค่าสถานะความไม่ตรงกันของสตริงรูปแบบระหว่าง msgid และ msgstr ก่อนที่จะไปถึงการผลิต — เป็นการป้องกันราคาถูกจากข้อผิดพลาดของตัวยึดตำแหน่งที่เสียหายซึ่งทำให้เค้าโครงที่แปลเสียหายโดยไม่รู้ตัว

วิธีที่ 3: Poedit (คอมไพล์เมื่อบันทึก)

หากคุณแก้ไขการแปลในโปรแกรมแก้ไขแบบกราฟิก Poedit จะคอมไพล์ให้คุณโดยอัตโนมัติ ทุกครั้งที่คุณบันทึกไฟล์ .po Poedit จะเขียนไฟล์ .mo ที่ตรงกันไว้ข้างๆ — ไม่ต้องใช้คำสั่งแยกต่างหาก ไม่ต้องมีขั้นตอนเพิ่มเติม

นี่เป็นเหตุผลหนึ่งที่ Poedit ยังคงเป็นที่นิยมในหมู่นักแปลที่ไม่คุ้นเคยกับการใช้บรรทัดคำสั่ง คุณเปิดไฟล์ .po พิมพ์คำแปลของคุณ กดบันทึก และไฟล์ทั้งสองจะอัปเดตพร้อมกัน คุณสามารถยืนยันพฤติกรรมนี้ได้ภายใต้การตั้งค่าของ Poedit ซึ่งการคอมไพล์ .mo อัตโนมัติเมื่อบันทึกจะถูกเปิดใช้งานโดยค่าเริ่มต้น Poedit และเครื่องมือเดสก์ท็อปที่คล้ายกันได้รับการรีวิวใน 5 เครื่องมือฟรีที่ดีที่สุดในการแก้ไขและแปลไฟล์ PO บน Mac และ Windows.

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

วิธีที่ 4: เครื่องมือคลาวด์ที่สร้างไฟล์ .mo ให้คุณ

ตัวเลือกที่สี่จะขจัดขั้นตอนการคอมไพล์ออกไปโดยสิ้นเชิง: ใช้บริการคลาวด์ที่จะส่งคืนไฟล์ .mo ที่คอมไพล์แล้วพร้อมกับไฟล์ .po ที่แปลแล้ว คุณไม่เคยต้องรันคำสั่งหรือบันทึกไฟล์สองครั้ง — คุณอัปโหลด แล้วไฟล์ที่สมบูรณ์และตั้งชื่อถูกต้องจะกลับมา

SimplePoTranslate ทำงานในลักษณะนี้อย่างแน่นอน คุณอัปโหลดไฟล์ .po หรือ .pot มันจะแปลสตริงด้วย Context-Aware AI และส่งคืนไฟล์ ZIP ไฟล์เดียวที่มี .po และ .mo ที่สร้างขึ้นเคียงข้างกัน — คอมไพล์แล้ว ตั้งชื่อให้ตรงกับ text domain และ locale ของคุณแล้ว ไม่มีการคอมไพล์แยกต่างหาก และไม่มีโอกาสที่จะลืม

นอกจากนี้ยังจัดการรายละเอียดที่ทำให้เวิร์กโฟลว์แบบแมนนวลเสียหายอีกด้วย Syntax Locking จะตรึงตัวยึดตำแหน่ง เช่น %s, %1$s และ {name} รวมถึงแท็ก HTML ก่อนการแปล เพื่อให้ตัวแปรของคุณยังคงอยู่ในไฟล์ .mo ได้อย่างสมบูรณ์ การรองรับ Gettext plural อย่างเต็มรูปแบบหมายความว่ารูปแบบพหูพจน์ที่ซับซ้อนก็คอมไพล์ได้อย่างถูกต้องเช่นกัน — เป็นหัวข้อที่ควรทำความเข้าใจอย่างลึกซึ้ง ซึ่งเราได้กล่าวถึงใน understanding Gettext plurals และเนื่องจากทำงานบนคลาวด์ จึงไม่มีปลั๊กอินให้ติดตั้งและไม่มีเครื่องมือสร้างที่ต้องดูแลรักษา

ข้อผิดพลาดที่พบบ่อยที่สุด: คุณลืมคอมไพล์ใหม่

เหตุผลที่ใหญ่ที่สุดที่ทำให้การแปลไม่ปรากฏขึ้นคือการแก้ไขไฟล์ .po แต่ลืมคอมไพล์ไฟล์ .mo ใหม่ WordPress ยังคงโหลดไบนารีเก่า ดังนั้นคำแปลใหม่ของคุณจึงไม่ปรากฏ — และไม่มีข้อความแสดงข้อผิดพลาดที่จะบอกคุณว่าทำไม

แบบจำลองทางความคิดที่ต้องยึดถือ: ไฟล์ .po คือฉบับร่างของคุณ ไฟล์ .mo คือสิ่งที่ถูกนำไปใช้จริง การเปลี่ยนแปลงใดๆ ในไฟล์ .po จะไม่ปรากฏต่อ WordPress จนกว่าคุณจะสร้างไฟล์ .mo ใหม่ ทำให้การคอมไพล์ใหม่เป็นปฏิกิริยาอัตโนมัติหลังจากการแก้ไขทุกครั้ง หรือใช้เครื่องมือที่คอมไพล์โดยอัตโนมัติเพื่อให้ไม่พลาดขั้นตอนดังกล่าว

ข้อผิดพลาดนี้แฝงตัวอยู่ในการส่งมอบจาก staging ไป production โดยเฉพาะ นักพัฒนาแก้ไขและคอมไพล์ในเครื่อง เห็นว่าการแปลทำงานได้ จากนั้นปรับใช้เฉพาะไฟล์ .po และลืมไฟล์ .mo — ทำให้ production ยังคงใช้ข้อความเก่าโดยไม่มีการแจ้งเตือน เมื่อใดก็ตามที่คุณย้ายไฟล์การแปลระหว่างสภาพแวดล้อม ให้ย้ายไฟล์ .po และไฟล์ .mo ที่คอมไพล์ใหม่พร้อมกัน หรือคอมไพล์เป็นส่วนหนึ่งของขั้นตอนการปรับใช้ เพื่อให้ไบนารีถูกสร้างใหม่จากต้นฉบับปัจจุบันเสมอ

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

หมายเหตุเกี่ยวกับรูปแบบ .l10n.php ที่ใหม่กว่า

WordPress เวอร์ชันล่าสุดได้นำเสนอรูปแบบรันไทม์ที่สาม: .l10n.php แทนที่จะเป็นไฟล์ไบนารี .mo การแปลจะถูกจัดเก็บเป็นอาร์เรย์ PHP ธรรมดาที่แคช PHP opcode สามารถเก็บไว้ในหน่วยความจำได้ ทำให้การค้นหาเร็วกว่า .mo ในเว็บไซต์ที่มีการใช้งานสูง

<?php
return [
	'domain'  => 'my-plugin',
	'messages' => [ 'Your cart is empty' => 'Ihr Warenkorb ist leer' ],
];

WordPress สร้างไฟล์ .l10n.php โดยอัตโนมัติเมื่อมีไฟล์ .mo ที่ตรงกันอยู่ ดังนั้นคุณไม่จำเป็นต้องสร้างด้วยตนเอง สำหรับตอนนี้ การคอมไพล์ไฟล์ .mo ที่ถูกต้องยังคงเป็นพื้นฐาน — รูปแบบประสิทธิภาพได้มาจากไฟล์นี้

สรุป

ในการคอมไพล์ .po เป็น .mo อย่างน่าเชื่อถือ ให้เลือกวิธีที่ตรงกับวิธีการทำงานของคุณ: WP-CLI สำหรับการทำงานแบบแบตช์ผ่านบรรทัดคำสั่ง, msgfmt สำหรับไฟล์เดียวพร้อมสถิติ, Poedit สำหรับการคอมไพล์อัตโนมัติเมื่อบันทึก หรือเครื่องมือคลาวด์ที่สร้างไฟล์ .mo ให้คุณเพื่อไม่ให้พลาดขั้นตอนดังกล่าว ทั้งสี่วิธีนี้สร้างไฟล์ไบนารีเดียวกันที่ WordPress ต้องการในขณะรันไทม์

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

พร้อมที่จะข้ามขั้นตอนการคอมไพล์ด้วยตนเองตลอดไปแล้วหรือยัง? ลอง SimplePoTranslate ฟรี — ไม่ต้องใช้บัตรเครดิต อัปโหลดไฟล์ .po ของคุณและดาวน์โหลดชุด .po + .mo ที่พร้อมใช้งานในระดับฟรีได้ภายในไม่กี่นาที