วิธีแปลภาษา RTL ใน WordPress: อารบิก ฮิบรู เปอร์เซีย
คุณเพิ่งแปลธีม WordPress ของคุณเป็นภาษาอารบิกเสร็จสิ้น คุณอัปโหลดไฟล์ .mo เปลี่ยนภาษาของไซต์ แต่ผลลัพธ์ที่ได้กลับอ่านไม่ออก ข้อความล้นไปทางซ้าย ปุ่มทับซ้อนกัน และเลย์เอาต์ที่คุณออกแบบอย่างพิถีพิถันดูเหมือนถูกป้อนเข้าเครื่องทำลายเอกสาร
ยินดีต้อนรับสู่โลกของภาษาที่เขียนจากขวาไปซ้าย (RTL) ซึ่งการแปลเป็นเพียงครึ่งหนึ่งของความท้าทาย
ภาษาอารบิก ฮิบรู และเปอร์เซีย (Farsi) เป็นหนึ่งในภาษาที่ใช้กันอย่างแพร่หลายมากที่สุดในโลก ภาษาอารบิกเพียงอย่างเดียวมีผู้พูดเป็นภาษาแม่มากกว่า 400 ล้านคน หากไซต์ WordPress ของคุณละเลยผู้ใช้งานเหล่านี้ คุณกำลังทิ้งเงินจำนวนมากไว้บนโต๊ะ แต่การให้บริการพวกเขาต้องใช้มากกว่าการสลับคำภาษาอังกฤษเป็นภาษาอารบิก ต้องมีการคิดใหม่เกี่ยวกับทิศทางของเลย์เอาต์ทั้งหมดของคุณ
คู่มือนี้ครอบคลุมทุกสิ่งที่คุณจำเป็นต้องรู้: วิธีการทำงานของ RTL ใน WordPress วิธีแก้ไข CSS วิธีจัดการไฟล์ .po ที่มีสตริง RTL และวิธีหลีกเลี่ยงข้อผิดพลาดที่พบบ่อยที่สุด
วิธีการทำงานของ RTL ใน WordPress
WordPress มีการรองรับ RTL ในตัว เมื่อคุณตั้งค่าภาษาของไซต์เป็นภาษาอารบิก (ar), ฮิบรู (he) หรือเปอร์เซีย (fa) WordPress จะเพิ่ม dir="rtl" ลงในแท็ก <html> โดยอัตโนมัติ และโหลดสไตล์ชีต rtl.css หากธีมของคุณมีให้
นี่คือทฤษฎี ในทางปฏิบัติ ธีมส่วนใหญ่มาพร้อมกับการรองรับ RTL ที่น้อยมากหรือใช้งานไม่ได้
สิ่งที่เปลี่ยนแปลงจริง
เมื่อโหมด RTL ทำงาน เบราว์เซอร์จะจำลองเลย์เอาต์ของหน้าทั้งหมด:
- ข้อความไหลจากขวาไปซ้าย
- แถบด้านข้างสลับด้าน
- เมนูนำทางเรียงลำดับย้อนกลับ
- ค่า Padding และ Margin พลิก (ซ้ายกลายเป็นขวา)
- ไอคอนที่มีความหมายเชิงทิศทาง (ลูกศร, เครื่องหมายเชฟรอน) จำเป็นต้องสะท้อน
หาก CSS ของธีมของคุณเขียนขึ้นสำหรับ LTR เท่านั้น การประกาศ margin-left, padding-right, float: left และ text-align: left ทุกรายการกำลังต่อสู้กับเอ็นจิน RTL ของเบราว์เซอร์
การแก้ไข CSS ของคุณสำหรับ RTL: คู่มือเชิงปฏิบัติ
แนวทางที่สะอาดที่สุดคือการใช้ CSS Logical Properties ซึ่งปรับให้เข้ากับทิศทางการเขียนของเอกสารโดยอัตโนมัติ แทนที่จะใช้ left และ right คุณใช้ inline-start และ inline-end
ก่อน: Physical Properties (เสียใน RTL)
/* LTR-only CSS -- breaks in Arabic */
.sidebar {
float: left;
margin-right: 20px;
}
.nav-arrow {
padding-left: 10px;
text-align: left;
}
.card {
border-left: 3px solid #0073aa;
}
หลัง: Logical Properties (ใช้งานได้ทั้งสองทิศทาง)
/* Direction-agnostic CSS -- works in both LTR and RTL */
.sidebar {
float: inline-start;
margin-inline-end: 20px;
}
.nav-arrow {
padding-inline-start: 10px;
text-align: start;
}
.card {
border-inline-start: 3px solid #0073aa;
}
ด้วย Logical Properties คุณเขียน CSS เพียงครั้งเดียวและใช้งานได้อย่างถูกต้องทั้งในภาษาอังกฤษและภาษาอารบิกโดยไม่ต้องมีการเขียนทับใดๆ
วิธีการเขียนทับ [dir="rtl"]
หากคุณไม่สามารถปรับโครงสร้างสไตล์ชีตทั้งหมดของคุณได้ คุณสามารถกำหนดเป้าหมาย RTL โดยเฉพาะโดยใช้ Attribute Selectors:
[dir="rtl"] .sidebar {
float: right;
margin-left: 20px;
margin-right: 0;
}
[dir="rtl"] .nav-arrow {
padding-left: 0;
padding-right: 10px;
text-align: right;
}
วิธีนี้ใช้งานได้ แต่จะเพิ่มภาระในการบำรุงรักษาเป็นสองเท่า ทุกครั้งที่คุณอัปเดตสไตล์ LTR คุณต้องอัปเดตการเขียนทับ RTL ด้วย
การแปลไฟล์ PO ด้วยสตริง RTL
การแปลด้วยตัวมันเองทำให้เกิดความท้าทายที่นอกเหนือไปจากเลย์เอาต์ ภาษา RTL มีลักษณะเฉพาะที่ทำให้เครื่องมืออัตโนมัติส่วนใหญ่สะดุด
ข้อความสองทิศทาง (Bidi) ในไฟล์ PO
ความซับซ้อนที่แท้จริงจะปรากฏขึ้นเมื่อข้อความ RTL และ LTR ผสมกันในสตริงเดียว ลองพิจารณารูปแบบ WordPress ทั่วไปนี้:
msgid "Powered by %s"
msgstr "مدعوم بواسطة %s"
ตัวยึดตำแหน่ง %s จะถูกแทนที่ด้วยชื่อผลิตภัณฑ์ภาษาอังกฤษ เช่น "WooCommerce" ในเอาต์พุตที่แสดงผล เบราว์เซอร์ต้องแสดงข้อความภาษาอารบิกที่ไหลจากขวาไปซ้าย จากนั้นสลับไปทางซ้ายไปขวาสำหรับคำภาษาอังกฤษ จากนั้นอาจสลับกลับ
สิ่งนี้เรียกว่า ข้อความสองทิศทาง (หรือ "bidi") และได้รับการจัดการโดย Unicode Bidirectional Algorithm ส่วนใหญ่มักจะทำงานโดยอัตโนมัติ แต่เมื่อคุณมีตัวยึดตำแหน่งหลายตัวหรือตัวเลขที่อยู่ติดกับข้อความ RTL ลำดับภาพอาจคาดเดาไม่ได้
ข้อผิดพลาดในการแปลทั่วไป
เครื่องมือแปลภาษาทั่วไปมักจะทำผิดพลาดเฉพาะสำหรับ RTL หลายประการ:
-
ลำดับตัวยึดตำแหน่งกลับกัน สตริงเช่น
%1$s out of %2$sอาจทำให้ตัวยึดตำแหน่งสลับกันเนื่องจาก AI จัดเรียงใหม่เพื่อให้ตรงกับไวยากรณ์ภาษาอารบิก สิ่งนี้จะสร้างเอาต์พุตที่ไม่ถูกต้องเช่น "10 out of Page" แทนที่จะเป็น "Page out of 10" เรียนรู้เพิ่มเติมเกี่ยวกับการ ปกป้องตัวแปรโค้ดระหว่างการแปล -
ทิศทาง HTML เสีย หากสตริงของคุณมี HTML แบบอินไลน์เช่น
<span dir="ltr">นักแปลที่ไร้เดียงสาอาจลบล้างแอตทริบิวต์dirหรือแปลมัน -
รูปแบบพหูพจน์หายไป ภาษาอารบิกมีรูปแบบพหูพจน์หกรูปแบบ – ศูนย์ หนึ่ง สอง น้อย มาก และอื่น ๆ นี่คือระบบพหูพจน์ที่ซับซ้อนที่สุดในบรรดาภาษาที่ WordPress รองรับ เครื่องมือที่สร้างเพียงสองรูปแบบ (เช่น เอกพจน์/พหูพจน์ภาษาอังกฤษ) จะทำให้ไฟล์
.poภาษาอารบิกของคุณเสีย สำหรับการเจาะลึกวิธีการทำงานของ Gettext Plurals โปรดดูคู่มือของเราเกี่ยวกับ Complex Pluralization ใน WordPress
นี่คือลักษณะของสตริงพหูพจน์ภาษาอารบิกที่แปลอย่างถูกต้องในไฟล์ .po:
# Arabic: nplurals=6
msgid "%d comment"
msgid_plural "%d comments"
msgstr[0] "لا تعليقات"
msgstr[1] "تعليق واحد"
msgstr[2] "تعليقان"
msgstr[3] "%d تعليقات"
msgstr[4] "%d تعليقًا"
msgstr[5] "%d تعليق"
หากรูปแบบทั้งหกนั้นว่างเปล่าหรือไม่ถูกต้อง WordPress จะกลับไปใช้สตริงภาษาอังกฤษสำหรับจำนวนเฉพาะนั้น ผู้ใช้ของคุณจะเห็น "5 comments" เป็นภาษาอังกฤษกระจัดกระจายไปทั่วอินเทอร์เฟซภาษาอารบิกที่สมบูรณ์
การทดสอบการใช้งาน RTL ของคุณ
การแปลและการแก้ไข CSS ไม่เพียงพอ คุณต้องตรวจสอบผลลัพธ์ในเบราว์เซอร์จริง
รายการตรวจสอบการทดสอบอย่างรวดเร็ว
- เปลี่ยนภาษา WordPress เป็นภาษาอารบิกใน การตั้งค่า > ทั่วไป อย่าเพียงแค่เพิ่ม
dir="rtl"ด้วยตนเอง – ใช้การตั้งค่าภาษาจริงเพื่อให้ WordPress โหลดการเขียนทับ RTL ของตัวเอง - ตรวจสอบเมนูนำทาง พวกเขาสะท้อนหรือไม่? รายการแบบเลื่อนลงเปิดในทิศทางที่ถูกต้องหรือไม่?
- ตรวจสอบช่องฟอร์ม ข้อความที่ป้อนควรไหลจากขวาไปซ้าย ข้อความตัวยึดตำแหน่งควรจัดชิดขวา
- ตรวจสอบเนื้อหาแบบผสมทิศทาง สตริงที่มีทั้งภาษาอารบิกและภาษาอังกฤษ (เช่น ชื่อแบรนด์หรือ URL) ควรแสดงผลในลำดับภาพที่ถูกต้อง
- ทดสอบบนมือถือ ข้อบกพร่องของเลย์เอาต์ RTL มักจะรุนแรงกว่าบนหน้าจอขนาดเล็กที่มีพื้นที่สำหรับข้อผิดพลาดในการจัดตำแหน่งน้อยกว่า
หาก การแปลของคุณไม่ปรากฏขึ้น เลย ปัญหาอาจไม่เกี่ยวข้องกับ RTL – ตรวจสอบการคอมไพล์ไฟล์ .mo และเส้นทางไฟล์ของคุณก่อน
เคล็ดลับเครื่องมือนักพัฒนาเบราว์เซอร์
ใน Chrome DevTools คุณสามารถบังคับ RTL บนหน้าใดก็ได้ชั่วคราวโดยไม่ต้องเปลี่ยนการตั้งค่า WordPress:
/* Paste in DevTools console as: document.documentElement.dir = 'rtl' */
html {
direction: rtl;
}
สิ่งนี้ช่วยให้คุณดูตัวอย่างอย่างรวดเร็วว่าธีมของคุณจัดการ RTL อย่างไรก่อนที่คุณจะเริ่มแปล
การทำให้การแปล RTL เป็นไปโดยอัตโนมัติในวิธีที่ถูกต้อง
การแปลภาษา RTL ด้วยตนเองมีราคาแพงและช้า นักแปลภาษาอารบิกมืออาชีพคิดค่าบริการในอัตราพรีเมียม และการหาคนที่เข้าใจทั้งภาษาและไวยากรณ์ Gettext ที่เฉพาะเจาะจงของ WordPress เป็นเรื่องยาก
SimplePoTranslate แก้ปัญหานี้ด้วยเอ็นจิน Context-Aware AI ที่เข้าใจความท้าทายเฉพาะของ RTL โดยกำเนิด:
-
รูปแบบพหูพจน์ภาษาอารบิกทั้งหกรูปแบบ ถูกสร้างขึ้นโดยอัตโนมัติ เอ็นจินของเราอ่านส่วนหัว
Plural-Formsในไฟล์.poของคุณและสร้างจำนวนรูปแบบที่ภาษาเป้าหมายของคุณต้องการอย่างแน่นอน ไม่มีช่องmsgstrว่างเปล่า ไม่มีการสำรองภาษาอังกฤษ -
ความปลอดภัยของตัวยึดตำแหน่ง ตัวแปรเช่น
%s,%dและ%1$sถูกล็อคระหว่างการแปล AI ไม่สามารถจัดเรียงใหม่ ลบ หรือทำให้เสียหายได้ แม้ว่าไวยากรณ์ภาษาอารบิกจะแนะนำลำดับคำที่แตกต่างกันก็ตาม อ่านเพิ่มเติมเกี่ยวกับวิธีที่ การล็อคไวยากรณ์ปกป้องโค้ดของคุณ -
บริบทสองทิศทาง AI เข้าใจว่าสตริงแบบผสมทิศทางต้องมีการจัดการเป็นพิเศษและรักษาแอตทริบิวต์ทิศทาง HTML
ไม่ว่าคุณจะแปลธีมบล็อกสำหรับผู้ใช้งานภาษาฮิบรูหรือแปลร้านค้า WooCommerce ทั้งหมดเป็นภาษาเปอร์เซีย กระบวนการก็เหมือนกัน: อัปโหลดไฟล์ .po ของคุณ เลือกภาษาเป้าหมาย และดาวน์โหลดไฟล์ที่แปล เวิร์กโฟลว์ทั้งหมดใช้เวลาไม่กี่นาที ไม่กี่วัน
สำหรับคำแนะนำฉบับสมบูรณ์เกี่ยวกับกระบวนการแปลเป็นภาษาท้องถิ่นของ WordPress โปรดดูที่ คู่มือฉบับสมบูรณ์เกี่ยวกับการแปลเป็นภาษาท้องถิ่นของ WordPress
หยุดปฏิบัติกับ RTL เหมือนเป็นความคิดภายหลัง
ภาษาที่เขียนจากขวาไปซ้ายเป็นตัวแทนของผู้ใช้ที่มีศักยภาพกว่าพันล้านคน ภาษาอารบิกเป็นภาษาที่พูดกันมากที่สุดเป็นอันดับห้าของโลก ภาษาฮิบรูและเปอร์เซียให้บริการตลาดที่สำคัญในตะวันออกกลางและเอเชียกลาง
หากไซต์ WordPress ของคุณไม่สามารถให้บริการผู้ใช้เหล่านี้ด้วยประสบการณ์ที่ขัดเกลาและเป็นธรรมชาติ พวกเขาจะพบคู่แข่งที่ทำได้
ข่าวดี: WordPress มีโครงสร้างพื้นฐานอยู่แล้ว ธีมของคุณต้องการ CSS ที่เหมาะสม และไฟล์ .po ของคุณต้องการเครื่องมือแปลที่เคารพความซับซ้อนของภาษา RTL
พร้อมที่จะแปลไซต์ WordPress ของคุณเป็นภาษาอารบิก ฮิบรู หรือเปอร์เซียหรือไม่? เริ่มต้นได้ฟรีที่ SimplePoTranslate.com