แปลเทมเพลต Elementor และ Divi โดยไม่ทำให้เลย์เอาต์เสียหาย

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

คุณตรวจสอบไฟล์ .po คุณเห็นสตริงภาษาอังกฤษในโค้ด คุณแปลใหม่ ไม่มีอะไรเปลี่ยนแปลง คุณล้างแคช ไม่มีอะไรเปลี่ยนแปลง คุณเชื่อว่ามีบางอย่างเสีย จนกระทั่งมีคนในฟอรัมชี้ให้เห็นอย่างนุ่มนวลว่า: Elementor (และ Divi, Beaver Builder, และ Bricks) ไม่ได้จัดเก็บเนื้อหาในไฟล์ .po พวกมันไม่เคยทำ คุณกำลังต่อสู้กับปัญหาที่ไม่สามารถแก้ไขได้ด้วยวิธีการที่คุณใช้อยู่

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

ทำไม Elementor และ Divi จึงไม่ใช้ไฟล์ .po

ไฟล์ .po จัดเก็บสตริงที่อยู่ในโค้ด เช่น การเรียก __( 'Shop', 'mytheme' ) ที่กระจายอยู่ทั่วเทมเพลต PHP เครื่องมือ WP-CLI สามารถดึงสตริงเหล่านี้ออกมาเป็นเทมเพลต .pot นักแปลจะทำงานกับไฟล์ .po และไฟล์ .mo ที่คอมไพล์แล้วจะถูกโหลดในขณะรันไทม์

เนื้อหาของ Page Builder แตกต่างกัน เมื่อคุณพิมพ์ "Welcome to our store" ลงในวิดเจ็ตหัวเรื่องของ Elementor ข้อความนั้นจะไม่ได้อยู่ในไฟล์ PHP ใดๆ แต่มันจะถูกบันทึกเป็น JSON (สำหรับ Elementor) หรือชุด Shortcode (สำหรับ Divi) ในตาราง wp_postmeta โดยเชื่อมโยงกับโพสต์ที่คุณวางไว้

เนื้อหา Page Builder อยู่ที่ไหนกันแน่

Elementor จัดเก็บโครงสร้างวิดเจ็ตของแต่ละหน้าใน postmeta ภายใต้คีย์ _elementor_data เปิดโพสต์ใดๆ ในฐานข้อมูล คุณจะพบ JSON array ที่อธิบายทุกส่วน คอลัมน์ และวิดเจ็ต พร้อมการตั้งค่าและเนื้อหาภายใน:

{
  "id": "a1b2c3",
  "elType": "widget",
  "widgetType": "heading",
  "settings": {
    "title": "Welcome to our store",
    "size": "xl",
    "header_size": "h1"
  }
}

Divi จัดเก็บเนื้อหาหน้าเว็บเป็น shortcode ที่ฝังอยู่ใน post_content:

[et_pb_section][et_pb_row][et_pb_column type="4_4"]
  [et_pb_text]Welcome to our store[/et_pb_text]
[/et_pb_column][/et_pb_row][/et_pb_section]

Bricks, Beaver Builder และ Oxygen ก็ใช้รูปแบบเดียวกันในฟอร์แมตของตนเอง เนื้อหาเหล่านี้ไม่เคยถูกแตะต้องโดยไฟล์ .po / .mo เลย

สิ่งที่อยู่ในไฟล์ .po จริงๆ

ปลั๊กอิน Page Builder เองก็มีสตริง UI เช่น ป้ายกำกับปุ่มในเอดิเตอร์, ข้อความแสดงข้อผิดพลาด, การแจ้งเตือนผู้ดูแลระบบ สิ่งเหล่านี้อยู่ในไฟล์ .po และจะถูกแปลโดยไฟล์ .mo ของคุณใน wp-content/languages/plugins/ นี่คือสาเหตุที่ผู้คนมักสับสน: พวกเขาแปลสตริง "Elementor" และเห็น UI ของเอดิเตอร์เป็นภาษาสเปน แต่เนื้อหาจริงที่พวกเขาสร้างด้วยวิดเจ็ตเหล่านั้นยังคงเป็นภาษาอังกฤษ

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

ไฟล์ .po ครอบคลุมอะไรบ้างบนเว็บไซต์ที่สร้างด้วย Page Builder

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

ไฟล์ .po / .mo ใช้แปล

• สตริงเทมเพลตของธีม: get_template_part, ข้อความที่ hardcode ไว้ใน header.php, footer.php, functions.php
• สตริง UI ของปลั๊กอิน: การชำระเงินของ WooCommerce, ป้ายกำกับผู้ดูแลระบบของ Yoast, ป้ายกำกับฟิลด์ของ Contact Form 7
• UI ของปลั๊กอิน Page Builder: ปุ่มแก้ไขของ Elementor, ข้อความยืนยันการบันทึกของ Divi
• สตริงไดนามิกที่ปลั๊กอินแสดงผลไปยังหน้าเว็บไซต์: WooCommerce "Add to cart," "Out of stock," ยอดรวมในตะกร้าสินค้า

ไฟล์ .po / .mo ไม่ได้แปล

• ข้อความหัวเรื่อง, ย่อหน้า, ปุ่มที่พิมพ์ลงในวิดเจ็ต Elementor
• คำบรรยายภาพ, เอฟเฟกต์โฮเวอร์, ชื่อหัวข้อ Accordion ภายในโมดูล Divi
• เนื้อหาในเทมเพลตที่นำมาใช้ซ้ำได้, ส่วนส่วนกลาง, บล็อกที่บันทึกไว้
• ป้ายกำกับ CSS แบบกำหนดเอง หรือสคริปต์แบบอินไลน์ภายในวิดเจ็ตของ Builder

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

สองแนวทางในการแปล Page Builder

มีเพียงสองวิธีในการแปลเนื้อหา Page Builder และทั้งสองวิธีก็มีข้อดีข้อเสียที่แตกต่างกัน

แนวทางที่หนึ่ง: คัดลอกหน้าเว็บตามแต่ละภาษา

ใช้ปลั๊กอินหลายภาษาเช่น WPML, Polylang หรือ TranslatePress มันจะสร้างสำเนาของทุกหน้าสำหรับแต่ละภาษา ใน Elementor คุณจะคัดลอกเลย์เอาต์ทั้งหมดแล้วสลับข้อความในสำเนาแต่ละชุด ใน Divi คุณจะคัดลอกชุด Shortcode แล้วแปลข้อความที่อยู่ระหว่างแท็ก

ข้อดี: แต่ละภาษาสามารถมีเลย์เอาต์ที่ออกแบบอย่างอิสระได้ (มีประโยชน์เมื่อข้อความที่แปลยาวขึ้นและทำให้การออกแบบเดิมของคุณเสียหาย) เข้ากันได้เต็มที่กับ Visual Editor ของ Page Builder

ข้อเสีย: การขยายตัวเชิงเส้น — 5 ภาษาหมายถึงงานออกแบบเลย์เอาต์เพิ่มขึ้น 5 เท่า การเปลี่ยนแปลงการออกแบบใดๆ ต้องทำซ้ำ 5 ครั้ง ฐานข้อมูลเติบโตเร็วขึ้น การแคชยากขึ้น

แนวทางที่สอง: เลเยอร์การแปลสตริง

ปลั๊กอินบางตัว (Polylang Pro, โมดูล String Translation ของ WPML, TranslatePress) สามารถเปิดเผยสตริงแต่ละรายการภายในวิดเจ็ตของ Page Builder เพื่อการแปลได้ จากนั้นสลับเปลี่ยนในขณะแสดงผล คุณจะดูแลเลย์เอาต์เดียว และปลั๊กอินจะแปลสตริงในตำแหน่งนั้น

ข้อดี: แหล่งข้อมูลเดียวสำหรับเลย์เอาต์ การเปลี่ยนแปลงการออกแบบมีผลทุกที่

ข้อเสีย: ความยืดหยุ่นลดลงเมื่อข้อความที่แปลมีความยาวเปลี่ยนไปอย่างมาก วิดเจ็ตบางตัว (ที่ซับซ้อนซึ่งมีเนื้อหาซ้อนกัน, รายการไดนามิก, ฟอร์ม) ไม่เปิดเผยสตริงอย่างชัดเจน มีผลต่อประสิทธิภาพการแสดงผลแต่ละครั้ง

การเปรียบเทียบ Polylang vs WPML vs TranslatePress ของเราครอบคลุมถึงข้อดีข้อเสียของแต่ละปลั๊กอินโดยละเอียด

การรักษาโครงสร้างวิดเจ็ตให้ปลอดภัยระหว่างการแปล

ไม่ว่าคุณจะเลือกแนวทางใด เนื้อหาที่แปลจะต้องรักษาโครงสร้างของ Builder ไว้ หากนักแปลของคุณลบ Elementor shortcode, แทนที่ data attribute หรือจัดเรียงแท็กที่ซ้อนกันใหม่ วิดเจ็ตจะแสดงผลผิดพลาด

จุดอันตรายของ Elementor

วิดเจ็ต Elementor ฝัง shortcode และ dynamic tags ไว้ในการตั้งค่าข้อความ ช่องชื่อเรื่องของวิดเจ็ตหัวเรื่องอาจมี:

Welcome to <strong>our</strong> [user_name] store

[user_name] นั้นเป็น dynamic tag — Elementor จะแทนที่ด้วยชื่อผู้ใช้ที่เข้าสู่ระบบในขณะแสดงผล หากการแปลทำให้มันเสียหาย คุณจะได้เห็น "[user_name]" แสดงต่อผู้ใช้ตามตัวอักษร

ไอคอนภายในปุ่มใช้ class attributes ที่ไม่ควรแปล ข้อความ alt ของรูปภาพถูกจัดเก็บแยกต่างหากจาก URL รูปภาพ การจัดวางคอลัมน์ใช้การตั้งค่าเฉพาะจุดพัก (title_mobile, title_tablet) ที่ต้องจัดการเป็นรายกรณี

การซ้อนกันของ Divi Shortcode

Divi shortcode ซ้อนกันอย่างลึกซึ้ง: [et_pb_section][et_pb_row][et_pb_column][et_pb_text] นักแปลที่มองว่ากลุ่ม shortcode เป็นข้อความธรรมดาจะเข้ารหัสวงเล็บเหลี่ยม, แปลค่าแอตทริบิวต์ หรือทำแท็กปิดหายไป การกระทำเหล่านี้จะทำให้โมดูลเสียหายและ Divi จะไม่สามารถแสดงผลได้

รูปแบบที่ปลอดภัย

สำหรับ Builder ทั้งสอง การแปลจะต้อง:

1. แยกวิเคราะห์รูปแบบวิดเจ็ต (JSON สำหรับ Elementor, shortcode AST สำหรับ Divi)
2. ตรวจสอบโครงสร้างเพื่อระบุเฉพาะช่องข้อความที่ผู้ใช้มองเห็น
3. ล็อก shortcode, dynamic tags, HTML attributes และ inline CSS
4. ส่งเฉพาะส่วนที่เป็นข้อความให้กับนักแปลพร้อมบริบท
5. แทรกข้อความที่แปลกลับเข้าไปในโครงสร้างเดิม

นี่คือหลักการเดียวกับที่เอนจิ้นของเราใช้กับไฟล์ .po คู่มือการแปลไฟล์ .po โดยไม่ทำให้ตัวแปรโค้ดเสียหาย จะอธิบายรูปแบบของ %s และ Placeholder อย่างละเอียด ซึ่งเทียบเท่ากับ shortcode และ dynamic tags ใน Page Builder

ขั้นตอนการทำงานแบบผสมผสานที่ใช้งานได้จริง

สำหรับทีมส่วนใหญ่ วิธีแก้ปัญหาที่เป็นรูปธรรมคือการรวมแนวทางทั้งสองเข้าด้วยกัน

ขั้นตอนที่ 1: แปล UI ของธีมและปลั๊กอินผ่านไฟล์ .po

ส่งออกไฟล์ .pot จากธีมและปลั๊กอินหลักของคุณ (WooCommerce, Yoast, UI ของ Page Builder) แปลครั้งเดียวผ่านผู้ให้บริการแปลบนคลาวด์ที่รองรับรูปแบบ .po วางไฟล์ .mo ที่คอมไพล์แล้วลงใน wp-content/languages/ สิ่งนี้จะจัดการสตริงอินเทอร์เฟซ 80% ของเว็บไซต์ของคุณโดยแทบไม่ต้องบำรุงรักษาต่อเนื่อง

ขั้นตอนที่ 2: เลือกปลั๊กอินหลายภาษาสำหรับเนื้อหาไดนามิก

ติดตั้ง Polylang หรือ WPML สำหรับเนื้อหาโพสต์ หน้า และสินค้า กำหนดค่าโครงสร้าง URL (/es/, /fr/) และแท็ก hreflang สิ่งนี้จะช่วยให้คุณมีโครงสร้างพื้นฐานสำหรับเนื้อหาฐานข้อมูลแยกตามภาษา

ขั้นตอนที่ 3: คัดลอกเทมเพลต Page Builder ของคุณอย่างเลือกสรร

สำหรับหน้า Landing Page ที่มีการเข้าชมสูง, หน้าแรก และเนื้อหาทางการตลาดที่เป็นหัวใจสำคัญ ให้คัดลอกหน้าในแต่ละภาษาและแปลวิดเจ็ตด้วยตนเอง คุณจะได้รับการควบคุมการออกแบบอย่างเต็มที่ในส่วนที่สำคัญ

ขั้นตอนที่ 4: ใช้ String Translation สำหรับบล็อกที่ซ้ำกัน

สำหรับส่วนส่วนกลาง, เทมเพลตที่นำกลับมาใช้ใหม่ได้ และ CTA ในส่วนท้ายที่ปรากฏบนทุกหน้า ให้ใช้คุณสมบัติ String Translation ของปลั๊กอินหลายภาษาของคุณ อัปเดตที่เดียว, สลับเมื่อแสดงผล

ขั้นตอนที่ 5: ตรวจสอบคุณภาพ

เนื้อหา Page Builder ที่แปลแล้วควรรแสดงผลโดยไม่มีการเลื่อนของเลย์เอาต์ ภาษาที่ยาวกว่า (เยอรมัน, รัสเซีย) อาจทำให้ความกว้างของปุ่มเสียหาย ภาษาที่สั้นกว่า (จีน, ญี่ปุ่น) อาจทำให้มีช่องว่างที่ไม่สวยงาม ทดสอบแต่ละเทมเพลตในแต่ละภาษาก่อนเผยแพร่

ข้อผิดพลาดทั่วไปและวิธีหลีกเลี่ยง

กับดักบางอย่างที่ปรากฏในทุกโปรเจกต์การแปล Page Builder

ข้อความ Alt ของรูปภาพไม่ถูกแปล

ทั้ง Elementor และ Divi จัดเก็บข้อความ alt แยกตามแต่ละอินสแตนซ์ของวิดเจ็ต ไม่ใช่ใน Media Library การแปลรูปภาพต้นฉบับไม่ได้แปลข้อความ alt ในทุกวิดเจ็ตที่ใช้รูปภาพนั้น อัปเดตข้อความ alt ในแต่ละหน้าที่คัดลอก

ฟอร์มและฟิลด์ที่กำหนดเอง

แบบฟอร์มติดต่อที่ฝังอยู่ในวิดเจ็ตของ Page Builder มีสตริงของตัวเอง (ป้ายกำกับ, ข้อความตัวอย่าง, ข้อความตรวจสอบความถูกต้อง) โปรดดู คู่มือของเราเกี่ยวกับการแปล Gravity Forms และ Contact Form 7 สำหรับข้อมูลเกี่ยวกับฟอร์ม

วิดเจ็ตและเทมเพลตส่วนกลาง

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

การหมดอายุของแคชการแปล

Page Builder แคช HTML ที่แสดงผลอย่างรุนแรง หลังจากแปลแล้ว ให้ล้างแคชทั้งหมด รวมถึงแคช CSS ของ Elementor (Elementor > Tools > Regenerate CSS) และแคช CSS แบบคงที่ของ Divi

สรุปทั้งหมด

การแปลเว็บไซต์ที่สร้างด้วย Elementor หรือ Divi ไม่ได้ยากกว่าการแปลธีมแบบ Static เพียงแต่ต้องใช้โมเดลความคิดที่ถูกต้อง สตริงของธีมและปลั๊กอินอยู่ในไฟล์ .po และส่งผ่านทางไฟล์ .mo เนื้อหาของ Page Builder อยู่ในฐานข้อมูลและส่งผ่านทางปลั๊กอินหลายภาษาหรือการคัดลอกด้วยตนเอง การสับสนระหว่างสองแนวทางนี้เป็นสาเหตุที่พบบ่อยที่สุดของความหงุดหงิดที่ว่า "ทำไมการแปลของฉันถึงไม่ทำงาน"

ขั้นตอนการทำงานที่ประสบความสำเร็จนั้นเรียบง่าย: ไฟล์ .mo แบบ static สำหรับทุกอย่างที่อยู่ในโค้ด, ปลั๊กอินหลายภาษาสำหรับเนื้อหาหน้าเว็บ, และการดูแลด้วยตนเองสำหรับหน้า Landing Page ที่มีคุณค่าสูง ไม่มีเครื่องมือใดเครื่องมือเดียวที่จัดการได้ทั้งสามอย่างนี้ และใครก็ตามที่รับปากอย่างอื่นกำลังหลอกขายบางอย่างให้คุณ

พร้อมที่จะแปลไฟล์ .po ของธีมและปลั๊กอินของคุณโดยไม่ทำให้โครงสร้างวิดเจ็ตเสียหายแล้วหรือยัง? ทดลองใช้ SimplePoTranslate ฟรี - ไม่ต้องใช้บัตรเครดิต อัปโหลด .po, ดาวน์โหลดคำแปลที่ปลอดภัย, แล้ววางลงใน wp-content/languages/