ไฟล์เดียวเข้า ห้าฟอร์แมตออก: วิธีรับประกันงานแปล WordPress ของคุณในอนาคต

คุณใช้เวลาสามสัปดาห์ในการแปลธีม WordPress ของคุณเป็นภาษาสเปน ไฟล์ .po สมบูรณ์แบบ — ทุกสตริงได้รับการตรวจสอบ ทุกตัวแปรยังคงอยู่ ทุกรูปแบบพหูพจน์ถูกต้อง จากนั้นลูกค้าของคุณตัดสินใจที่จะย้ายจากธีม PHP แบบคลาสสิกไปเป็นการตั้งค่า Headless ด้วย React บน Frontend

ทันใดนั้นไฟล์ .po ของคุณก็ไร้ประโยชน์ แอป React ต้องการ .json วิดเจ็ต PHP แบบเดิมยังคงต้องการ .mo ฟรีแลนซ์ที่จัดการแอปบนมือถือต้องการ .xliff และไม่มีใครมีเวลาแปลสตริง 4,000 สตริงเป็นสามรูปแบบที่แตกต่างกัน

นี่ไม่ใช่กรณีพิเศษ เป็นความจริงของการพัฒนา WordPress สมัยใหม่ ซึ่งธีมมาพร้อมกับทั้งส่วนประกอบ PHP และ JavaScript ปลั๊กอินใช้ Gettext และ i18next ผสมกัน และลูกค้าเปลี่ยนใจเกี่ยวกับสถาปัตยกรรมบ่อยกว่าที่พวกเขาเปลี่ยนรหัสผ่าน

ทำไมรูปแบบไฟล์แปลจึงสำคัญกว่าที่เคย

เมื่อห้าปีที่แล้ว การแปล WordPress เป็นเรื่องง่าย คุณมีไฟล์ .po (แหล่งที่มาที่มนุษย์อ่านได้) และไฟล์ .mo (ไบนารีที่คอมไพล์แล้ว) แค่นั้น ธีมทุกธีม ปลั๊กอินทุกตัว และเครื่องมือแปลทุกตัวพูดภาษาเดียวกัน

วันนี้ ระบบนิเวศ WordPress ใช้รูปแบบไฟล์แปลอย่างน้อยห้ารูปแบบในการผลิต:

ห้ารูปแบบที่คุณต้องรู้

.po (Portable Object) — รูปแบบแหล่งที่มาที่มนุษย์อ่านได้ซึ่งใช้โดย GNU Gettext ประกอบด้วยสตริงดั้งเดิม (msgid) และการแปล (msgstr) นี่คือสิ่งที่นักแปลแก้ไข

msgid "Add to Cart"
msgstr "Anadir al carrito"

msgid "Your order has been shipped to %s"
msgstr "Su pedido ha sido enviado a %s"

.mo (Machine Object) — เวอร์ชันไบนารีที่คอมไพล์แล้วของไฟล์ .po WordPress อ่านไฟล์ .mo ในรันไทม์โดยใช้ load_textdomain() เร็วกว่าการแยกวิเคราะห์ .po ในรันไทม์ แต่แก้ไขไม่ได้โดยมนุษย์

.json (JavaScript Object Notation) — ใช้โดย wp_set_script_translations() สำหรับการแปลที่ใช้ JavaScript ในบล็อก Gutenberg ส่วนประกอบ React และธีมสมัยใหม่ WordPress คาดหวังโครงสร้าง JSON ที่เฉพาะเจาะจงด้วยคีย์ locale_data

{
  "locale_data": {
    "flavor-starter": {
      "Add to Cart": ["Anadir al carrito"],
      "Your order has been shipped to %s": ["Su pedido ha sido enviado a %s"]
    }
  }
}

.php (PHP Array) — รูปแบบที่ได้รับความนิยมมากขึ้นสำหรับธีมและปลั๊กอินที่ใช้การโหลดการแปลสไตล์ Laravel ธีม WordPress สมัยใหม่บางธีมเลี่ยง Gettext โดยสมบูรณ์และโหลดการแปลจากอาร์เรย์ PHP เพื่อประสิทธิภาพ

<?php
return [
    'Add to Cart' => 'Anadir al carrito',
    'Your order has been shipped to %s' => 'Su pedido ha sido enviado a %s',
];

.xliff (XML Localization Interchange File Format) — มาตรฐานอุตสาหกรรมสำหรับการแลกเปลี่ยนการแปลระหว่างเครื่องมือและแพลตฟอร์มต่างๆ ใช้โดยเครื่องมือ CAT (Computer-Assisted Translation) เช่น memoQ, Trados และ Memsource จำเป็นเมื่อทำงานร่วมกับนักแปลที่เป็นมนุษย์มืออาชีพ

<trans-unit id="1">
  <source>Add to Cart</source>
  <target>Anadir al carrito</target>
</trans-unit>

ปัญหา: การผูกมัดกับรูปแบบ

เครื่องมือแปลส่วนใหญ่สร้างรูปแบบเอาต์พุตเดียว Poedit ให้ .po และ .mo WPML จัดเก็บการแปลในฐานข้อมูล (ไม่ใช่ในไฟล์เลย) Weglot เก็บการแปลไว้ในเซิร์ฟเวอร์ของตนในรูปแบบที่เป็นกรรมสิทธิ์ แม้แต่แพลตฟอร์ม TMS เช่น Crowdin และ Lokalise ก็ต้องการให้คุณกำหนดค่ารูปแบบการส่งออกด้วยตนเองสำหรับแต่ละโครงการ

สิ่งนี้สร้าง การผูกมัดกับรูปแบบ — การแปลของคุณติดอยู่ในรูปแบบที่เครื่องมือปัจจุบันของคุณสร้างขึ้น เมื่อความต้องการของคุณเปลี่ยนไป คุณต้องเผชิญกับสองทางเลือก:

1. แปลทุกอย่างใหม่ ในรูปแบบใหม่ (มีราคาแพง ใช้เวลานาน และคุณสูญเสียการแก้ไขด้วยตนเอง)
2. เขียนสคริปต์การแปลงที่กำหนดเอง (มีข้อผิดพลาดได้ง่าย โดยเฉพาะอย่างยิ่งสำหรับ รูปแบบพหูพจน์ที่ซับซ้อน และตัวแปร)

ไม่มีตัวเลือกใดดี ทั้งสองอย่างเสียเวลาและเงิน ทั้งสองอย่างนำมาซึ่งความเสี่ยง

สถานการณ์จริงที่การผูกมัดกับรูปแบบส่งผลเสีย

สถานการณ์ที่ 1: การปรับปรุงธีมให้ทันสมัย ธีมของลูกค้าของคุณกำลังถูกสร้างใหม่ด้วยบล็อก Gutenberg เทมเพลต PHP เก่าใช้ไฟล์ .mo บล็อกใหม่ต้องการ .json สำหรับ wp_set_script_translations() สตริงที่แปลแล้ว 3,000 สตริงของคุณต้องมีอยู่ในทั้งสองรูปแบบในช่วงเปลี่ยนผ่าน

สถานการณ์ที่ 2: ขั้นตอนการทำงานของเอเจนซี คุณจัดการเว็บไซต์ลูกค้า 20 แห่ง บางแห่งใช้ธีมคลาสสิก (.mo) บางแห่งใช้การตั้งค่า Headless (.json) หนึ่งแห่งใช้เฟรมเวิร์กที่กำหนดเองที่อ่านอาร์เรย์ PHP คุณต้องมีการแปลเดียวกันในรูปแบบต่างๆ สำหรับลูกค้าที่แตกต่างกัน

สถานการณ์ที่ 3: การตรวจสอบโดยผู้เชี่ยวชาญ การแปลด้วย AI ของคุณแม่นยำ 95% แต่คุณต้องการให้เจ้าของภาษาตรวจสอบส่วนที่เหลืออีก 5% นักแปลมืออาชีพใช้เครื่องมือ CAT ที่นำเข้า .xliff คุณต้องส่งออกการแปลของคุณเป็น .xliff ส่งไปให้ตรวจสอบ และรวมการแก้ไขกลับคืน

สถานการณ์ที่ 4: การย้ายแพลตฟอร์ม ลูกค้าของคุณกำลังย้ายจาก WordPress ไปยังแอปพลิเคชัน Node.js ที่กำหนดเอง แอปใหม่ใช้ i18next และต้องการไฟล์ .json สตริงที่แปลแล้ว 5,000 สตริงของคุณในรูปแบบ .po ต้องถูกแปลง — โดยไม่สูญเสียตัวแปรหรือรูปแบบพหูพจน์ใดๆ

ทางออก: แปลครั้งเดียว รับทุกรูปแบบ

SimplePoTranslate ใช้วิธีการที่แตกต่างออกไป เมื่อคุณอัปโหลดไฟล์ .po, .pot, .json หรือ .xliff และเรียกใช้งานการแปล คุณจะได้รับ ZIP ที่มี ทั้งห้ารูปแบบ:

translations-es_ES.zip
├── flavor-starter-es_ES.po
├── flavor-starter-es_ES.mo
├── flavor-starter-es_ES.json
├── flavor-starter-es_ES.php
└── flavor-starter-es_ES.xliff

นี่ไม่ใช่ "คุณสมบัติระดับพรีเมียม" ที่ถูกล็อคไว้เบื้องหลังระดับองค์กร ทุกแผนแบบชำระเงิน — Pro (19 ดอลลาร์/เดือน) และ Lifetime (399 ดอลลาร์ครั้งเดียว) — รวมรูปแบบเอาต์พุตทั้งห้าในทุกงานแปล

ทำไมสิ่งนี้จึงสำคัญต่อการรับประกันอนาคต

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

• ลูกค้าย้ายจากแบบคลาสสิกไปเป็น Gutenberg หรือไม่? ปรับใช้ไฟล์ .json
• นักพัฒนาใหม่ชอบอาร์เรย์ PHP หรือไม่? ส่งไฟล์ .php ให้พวกเขา
• นักแปลมืออาชีพต้องการตรวจสอบหรือไม่? ส่งไฟล์ .xliff
• กำลังย้ายไปใช้ CMS อื่นหรือไม่? ไฟล์ .json และ .xliff เป็นอิสระจากแพลตฟอร์ม

คุณแปลครั้งเดียว รูปแบบต่างๆ พร้อมใช้งานเมื่อคุณต้องการ

รูปแบบแต่ละรูปแบบทำงานอย่างไรใน WordPress

การทราบว่าไฟล์ใดไปที่ไหนเป็นสิ่งสำคัญสำหรับการปรับใช้ที่สะอาด

การปรับใช้ไฟล์ .mo (ธีมและปลั๊กอิน PHP แบบคลาสสิก)

wp-content/languages/plugins/woocommerce-es_ES.mo
wp-content/languages/themes/flavor-starter-es_ES.mo

WordPress โหลดสิ่งเหล่านี้โดยอัตโนมัติเมื่อภาษาของไซต์ตรงกัน ไม่จำเป็นต้องใช้ปลั๊กอิน ไม่มีค่าใช้จ่ายฐานข้อมูลเพิ่มเติม นี่คือแนวทางที่ให้ ประสิทธิภาพที่ดีที่สุด

การปรับใช้ไฟล์ .json (บล็อก Gutenberg และส่วนประกอบ JS)

wp-content/languages/plugins/woocommerce-es_ES-{handle}-{md5}.json

ชื่อไฟล์ประกอบด้วย Script Handle และแฮช MD5 WordPress จับคู่สิ่งเหล่านี้เมื่อคุณเรียก wp_set_script_translations() ในปลั๊กอินหรือธีมของคุณ หากคุณกำลังสร้างบล็อก Gutenberg นี่คือไฟล์ที่ทำให้ป้ายกำกับและคำอธิบายบล็อกที่แปลแล้วของคุณปรากฏอย่างถูกต้อง

การใช้ไฟล์ .xliff (ขั้นตอนการทำงานของการตรวจสอบโดยผู้เชี่ยวชาญ)

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

1. อัปโหลด .po ไปยัง SimplePoTranslate และรับ .xliff ใน ZIP
2. ส่ง .xliff ไปยังนักแปลหรือผู้ตรวจสอบของคุณ
3. รับ .xliff ที่แก้ไขแล้วกลับคืน
4. อัปโหลด .xliff ที่แก้ไขแล้วไปยัง SimplePoTranslate และรับ .mo และ .json ที่อัปเดตแล้ว

ขั้นตอนการทำงานแบบ Round-trip นี้จะรักษาทุกตัวแปรและรูปแบบพหูพจน์ไว้ เนื่องจาก Syntax Locking ของ SimplePoTranslate ปกป้องสิ่งเหล่านั้นในทุกขั้นตอน

การทดสอบการผูกมัดกับผู้ขาย

นี่คือการทดสอบง่ายๆ เพื่อตรวจสอบว่าขั้นตอนการทำงานของการแปลปัจจุบันของคุณมีปัญหาการผูกมัดหรือไม่:

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

หากคำตอบสำหรับคำถามใดๆ เหล่านี้คือ "ไม่" แสดงว่าคุณถูกผูกมัด บริการต่างๆ เช่น Weglot และ GTranslate สอบตกทั้งสามคำถาม — ยกเลิกการสมัครสมาชิกและการแปลของคุณจะหายไป WPML จัดเก็บการแปลในฐานข้อมูล ทำให้สามารถส่งออกได้ แต่เจ็บปวด แม้แต่เครื่องมือเดสก์ท็อปเช่น Poedit ก็ผ่านการทดสอบบนกระดาษ แต่จำกัดคุณไว้ที่ .po และ .mo เท่านั้น

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

การสร้างไลบรารีการแปลที่ไม่ขึ้นกับรูปแบบ

สำหรับเอเจนซีและนักพัฒนาที่จัดการหลายโครงการ แนวทางที่ชาญฉลาดที่สุดคือการสร้าง ไลบรารีการแปล — ที่เก็บ Git หรือโฟลเดอร์ที่แชร์ที่คุณจัดเก็บไฟล์ที่แปลแล้วสำหรับทุกโครงการของลูกค้า

translations/
├── client-acme/
│   ├── es_ES/
│   │   ├── flavor-starter-es_ES.po
│   │   ├── flavor-starter-es_ES.mo
│   │   ├── flavor-starter-es_ES.json
│   │   ├── flavor-starter-es_ES.php
│   │   └── flavor-starter-es_ES.xliff
│   └── de_DE/
│       └── ...
├── client-globex/
│   └── ...

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

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

พร้อมที่จะหยุดกังวลเกี่ยวกับรูปแบบไฟล์แล้วหรือยัง ลองใช้ SimplePoTranslate ฟรี — อัปโหลดไฟล์หนึ่งไฟล์ รับห้ารูปแบบกลับคืน ไม่มีสคริปต์การแปลง ไม่มีการแปลใหม่ ไม่มีการผูกมัด