คู่มือฉบับสมบูรณ์สำหรับการแปลเว็บไซต์ WordPress หลายภาษา

การแปลเว็บไซต์ WordPress เป็นกระบวนการที่ซับซ้อนซึ่งต้องอาศัยการวางแผนและการดำเนินการอย่างรอบคอบ เราได้จัดทำคู่มือฉบับสมบูรณ์นี้จากประสบการณ์อันยาวนานในการแปลเว็บไซต์ โดยใช้ปลั๊กอิน Gato AI Translations for Polylang

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

​

ติดตั้งและกำหนดค่า Polylang

Gato AI Translations for Polylang ต้องการให้ติดตั้งและเปิดใช้งาน Polylang ก่อน Polylang คือเฟรมเวิร์กหลายภาษาที่จัดการภาษาและความสัมพันธ์ของการแปลของคุณ

หลังการติดตั้ง คุณจะต้องกำหนดค่า Polylang พร้อมภาษาของคุณ:

1. ไปที่ Languages ในเมนูผู้ดูแลระบบ WordPress ของคุณ
2. เพิ่มภาษาเริ่มต้นของคุณ (ภาษาของเนื้อหาที่มีอยู่)
3. เพิ่มภาษาเป้าหมายทั้งหมดที่คุณต้องการแปล

​

ตรวจสอบและแก้ไขเนื้อหาต้นฉบับก่อน

ก่อนที่คุณจะเริ่มแปล สิ่งสำคัญคือต้องมั่นใจว่าเนื้อหาต้นฉบับของคุณอยู่ในสภาพสมบูรณ์แบบ ปัญหาใดๆ ในเนื้อหาต้นฉบับจะถูกทำซ้ำไปยังการแปลทั้งหมด หมายความว่าคุณจะต้องแก้ไขปัญหาเดิมหลายครั้ง (ครั้งละหนึ่งภาษา)

รายการตรวจสอบเนื้อหา:

1. ตรวจสอบลิงก์เสีย

   • ใช้ปลั๊กอินอย่าง Broken Link Checker เพื่อระบุลิงก์ภายในและภายนอกที่เสีย
   • แก้ไขลิงก์เสียทั้งหมดก่อนแปล
   • ตรวจสอบว่าลิงก์ภายในชี้ไปยังโพสต์/หน้าที่ถูกต้อง

2. ตรวจสอบว่ารูปภาพทั้งหมดมีอยู่และได้รับการปรับแต่งแล้ว

   • ตรวจสอบว่ารูปภาพทั้งหมดโหลดได้ถูกต้อง
   • ตรวจสอบว่ารูปภาพมีข้อความ alt ที่เหมาะสมสำหรับการเข้าถึงและ SEO
   • ตรวจสอบว่าขนาดไฟล์รูปภาพสมเหตุสมผล (ไม่ใหญ่เกินไป)
   • ลบรูปภาพ placeholder หรือการอ้างอิงรูปภาพที่เสียออก

3. ตรวจสอบการจัดรูปแบบและสไตล์

   • ตรวจสอบว่าการจัดรูปแบบข้อความมีความสม่ำเสมอ
   • ตรวจสอบว่าหัวเรื่องมีโครงสร้างที่ถูกต้อง (H1, H2, H3 เป็นต้น)
   • ตรวจสอบว่ารายการ ตาราง และเนื้อหาที่มีโครงสร้างอื่นๆ แสดงผลถูกต้อง
   • ทดสอบว่าสไตล์และ CSS ที่กำหนดเองทำงานตามที่คาดหวัง

4. ตรวจสอบโครงสร้างเนื้อหา

   • ตรวจสอบการใช้บล็อก Gutenberg หรือองค์ประกอบ page builder ที่ถูกต้อง
   • ตรวจสอบว่า custom post types และ taxonomies ได้รับการตั้งค่าอย่างถูกต้อง
   • ตรวจสอบว่า metadata (custom fields, ACF fields เป็นต้น) ครบถ้วน

5. ตรวจสอบเนื้อหา placeholder

   • ลบข้อความ "Lorem ipsum" หรือข้อความ placeholder ออก
   • แทนที่เนื้อหาชั่วคราวด้วยเวอร์ชันสุดท้าย
   • ตรวจสอบว่าเนื้อหาทั้งหมดพร้อมสำหรับการเผยแพร่

6. ข้อพิจารณาด้าน SEO

   • ตรวจสอบว่าตั้งค่า meta titles และ descriptions แล้ว
   • ตรวจสอบว่า URL เป็นมิตรกับ SEO
   • ตรวจสอบการใช้หัวเรื่องที่เหมาะสมสำหรับโครงสร้าง SEO

​

กำหนดค่าการแทนที่ลิงก์ภายใน

เมื่อแปลเนื้อหา ลิงก์ภายในต้องได้รับการอัปเดตให้ชี้ไปยังเวอร์ชันที่แปลแล้ว Gato AI Translations for Polylang สามารถจัดการสิ่งนี้ให้คุณโดยอัตโนมัติ

ปลั๊กอินช่วยให้คุณกำหนดค่าประเภทลิงก์ภายในที่ควรถูกแทนที่:

• Custom Posts: ลิงก์ไปยังโพสต์อื่น หน้า custom post types เป็นต้น
• Media: ลิงก์ไปยังรายการสื่อ (รูปภาพ วิดีโอ เป็นต้น)
• Tags: ลิงก์ไปยังหน้า tag archive
• Categories: ลิงก์ไปยังหน้า category archive
• Users: ลิงก์ไปยังหน้าผู้เขียน

วิธีกำหนดค่า:

1. ไปที่หน้า Settings ภายใต้ Plugin Configuration > Internal Links Replacement
2. เปิดใช้งานเฉพาะประเภทลิงก์ที่คุณใช้จริงในเนื้อหาของคุณ
3. บันทึกการตั้งค่าของคุณ

​

ตรวจสอบว่าลิงก์ทั้งหมดใช้ URL ที่ถูกต้อง

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

• เนื้อหาโพสต์/หน้า (บล็อก Gutenberg, HTML เป็นต้น)
• วิดเจ็ต Elementor และ meta fields
• องค์ประกอบ Bricks builder และ meta fields
• Custom fields และ metadata

ข้อกำหนดของ URL:

1. URL ต้องรวมโดเมนเต็ม

   • ✅ ถูกต้อง: https://www.mysite.com/hello-world/
   • ❌ ไม่ถูกต้อง: /hello-world/ (URL แบบ relative)
   • ❌ ไม่ถูกต้อง: hello-world/ (ไม่มีโดเมนหรือโปรโตคอล)

2. URL ต้องชี้ไปยัง slug ปัจจุบัน

   • หากคุณเปลี่ยน slug ของโพสต์ ให้อัปเดตลิงก์ทั้งหมดให้ใช้ slug ใหม่
   • WordPress ต้องสามารถดึงโพสต์จาก URL ได้
   • slug เก่าที่ redirect จะไม่ทำงานสำหรับการแทนที่ลิงก์

3. URL ต้องใช้โดเมนที่ถูกต้อง (ไม่มีการ redirect)

   • ✅ ถูกต้อง: https://www.mysite.com/hello-world/
   • ❌ ไม่ถูกต้อง: https://mysite.com/hello-world/ (หากไซต์ของคุณใช้ www)
   • ปลั๊กอินต้องการโดเมนที่แน่นอนเพื่อจับคู่และแทนที่ลิงก์อย่างถูกต้อง

​

เลือกสถานะ Draft หรือ Publish

เมื่อสร้างการแปล คุณต้องตัดสินใจว่าควรเผยแพร่ทันทีหรือบันทึกเป็น draft เพื่อตรวจสอบก่อน

โดยค่าเริ่มต้น การแปลจะถูกบันทึกเป็น draft เพื่อให้การแปลถูกเผยแพร่ทันที ให้ไปที่หน้า Settings ภายใต้ Plugin Configuration > General Configuration และตั้งค่าตัวเลือก Status when translated เป็น Publish หรือ Same as origin post (หากโพสต์ต้นฉบับได้รับการเผยแพร่แล้ว)

​

การรองรับภาษา Right-to-Left (RTL)

หากคุณกำลังแปลเป็นภาษาที่เขียนจากขวาไปซ้าย เช่น ภาษาฮีบรู อาหรับ ฟาร์ซี หรืออูรดู คุณต้องตรวจสอบว่าธีมของคุณรองรับเลย์เอาต์ RTL อย่างถูกต้อง

สิ่งที่ RTL ส่งผลกระทบ:

ภาษา RTL ต้องการมากกว่าแค่การเปลี่ยนทิศทางข้อความ ธีมของคุณต้องจัดการกับ:

• ทิศทางของเลย์เอาต์: องค์ประกอบควรไหลจากขวาไปซ้าย
• การจัดตำแหน่งข้อความ: ข้อความควรจัดชิดขวาโดยค่าเริ่มต้น
• การปรับระยะห่าง: margin-left ควรกลายเป็น margin-right, padding-left ควรกลายเป็น padding-right เป็นต้น
• การนำทาง: เมนูและการนำทางควรไหลแบบ RTL
• ฟอร์ม: ช่องป้อนข้อมูลและปุ่มควรจัดตำแหน่งอย่างถูกต้อง
• ไอคอนและรูปภาพ: อาจต้องกลับด้านหรือปรับตำแหน่ง

สิ่งที่ได้รับการจัดการแล้ว:

• Polylang กำหนดทิศทางภาษาที่ถูกต้องโดยอัตโนมัติ (แอตทริบิวต์ dir="rtl")
• การแปลเนื้อหา ทำงานเหมือนกันสำหรับทั้งภาษา RTL และ LTR
• Gato AI Translations แปลเนื้อหาได้อย่างถูกต้องไม่ว่าจะเป็นทิศทางข้อความใด

สิ่งที่คุณต้องตรวจสอบ:

1. การรองรับ RTL ของธีม: ทดสอบธีมของคุณกับภาษา RTL เพื่อดูว่าจัดการได้ถูกต้องหรือไม่

   • ธีมสมัยใหม่หลายตัวมี RTL stylesheets รวมอยู่ด้วย
   • ตรวจสอบเอกสารของธีมสำหรับข้อมูลการรองรับ RTL
   • มองหาไฟล์ rtl.css หรือไฟล์ที่คล้ายกันในธีมของคุณ

2. CSS ที่กำหนดเอง: ตรวจสอบ CSS ที่กำหนดเองที่คุณเพิ่มไว้

   • ค่า left/right ที่ hard-coded อาจต้องปรับแต่ง
   • พิจารณาใช้ logical properties (margin-inline-start แทน margin-left)

3. ความเข้ากันได้กับ page builder: หากใช้ Elementor, Bricks หรือ page builders อื่นๆ

   • ตรวจสอบว่ารองรับเลย์เอาต์ RTL หรือไม่
   • ทดสอบเลย์เอาต์ในโหมด RTL ก่อนแปล

หากธีมของคุณไม่รองรับ RTL ได้ดี คุณอาจต้องเปลี่ยนไปใช้ธีมที่รองรับ RTL เพิ่ม CSS RTL ที่กำหนดเอง หรือใช้ปลั๊กอินที่เพิ่มการรองรับ RTL

​

ระบุเนื้อหาจากปลั๊กอินของบุคคลที่สามที่ต้องการแปล

ปลั๊กอิน WordPress หลายตัวสร้าง Custom Post Types (CPTs) ของตัวเองเพื่อจัดเก็บเนื้อหา (เช่น สินค้า WooCommerce, อีเวนต์ Events Calendar, คอร์ส LearnDash เป็นต้น)

ก่อนแปล คุณต้องดำเนินการดังนี้:

1. ระบุว่า CPTs ใดบ้างที่มีเนื้อหาที่ต้องแปล

   • ตรวจสอบปลั๊กอินที่ใช้งานอยู่และ CPTs ของแต่ละตัว
   • พิจารณาว่าอันไหนต้องการการแปล (ไม่จำเป็นต้องทุกอัน)

2. ตรวจสอบให้แน่ใจว่า CPTs และ taxonomies ที่เกี่ยวข้องสามารถแปลได้

   • ไปที่ Languages > Settings > Custom post types and Taxonomies ของ Polylang
   • เปิดใช้งานการแปลสำหรับ CPTs และ taxonomies ที่เกี่ยวข้อง

​

สร้างรายการแปลสำหรับ CPTs โดยอัตโนมัติ

หาก CPT ใช้เมธอด wp_insert_post ในการสร้างรายการ คุณสามารถไปที่หน้า Settings ในส่วน Plugin Configuration > General Configuration แล้วเปิดใช้งานตัวเลือก Automatic creation of translation entries สำหรับ CPT นั้น เพื่อให้ปลั๊กอินสร้างรายการแปลโดยอัตโนมัติ

​

ตรวจสอบว่าปลั๊กอิน SEO ของคุณรองรับหรือไม่

ข้อมูล SEO (meta title, description, Open Graph tag เป็นต้น) มีความสำคัญอย่างยิ่งสำหรับ SEO แบบหลายภาษา Gato AI Translations for Polylang มีการรองรับในตัวสำหรับปลั๊กอิน SEO ยอดนิยมที่สุด โดยแปลข้อมูล SEO ที่เกี่ยวข้องทั้งหมดโดยอัตโนมัติ

ปลั๊กอินนี้รองรับปลั๊กอิน SEO หลัก 8 ตัว:

1. All in One SEO
2. Rank Math
3. SEO Simple Pack
4. SEOPress
5. Slim SEO
6. The SEO Framework
7. WP Meta SEO
8. Yoast SEO

หากคุณใช้ปลั๊กอิน SEO ที่ไม่อยู่ในรายการข้างต้น คุณต้องระบุว่า meta key ใดบ้างที่ต้องการซิงโครไนซ์และแปล ตามที่ปลั๊กอิน SEO ของคุณใช้งาน ปลั๊กอินใดก็ตามที่จัดเก็บข้อมูลใน wp_postmeta table จะได้รับการรองรับ

​

เลือก AI Provider และโมเดลที่ต้องการ

คุณภาพของการแปลขึ้นอยู่กับบริการ AI และโมเดลที่คุณเลือก

บริการ AI สมัยใหม่ (เช่น ChatGPT, Claude, และ Gemini) ให้การแปลที่ดีกว่าบริการเดิม (Google Translate หรือ DeepL) อย่างมีนัยสำคัญ เนื่องจากเข้าใจบริบท น้ำเสียง และความละเอียดอ่อนได้ดีกว่า รักษาโครงสร้างและการจัดรูปแบบ HTML ได้อย่างถูกต้อง ไม่แปล URL หรือลิงก์สัมพัทธ์อย่างผิดพลาด คงรูปแบบการเขียนและน้ำเสียงไว้ตลอดการแปล และจัดการคำศัพท์ทางเทคนิคและภาษาเฉพาะทางได้ดีกว่า

คุณสามารถเลือกจากบริการ AI ต่อไปนี้:

• ChatGPT (OpenAI)
• Claude (Anthropic)
• DeepSeek
• Gemini (Google)
• Mistral AI
• OpenRouter (ตัวรวม LLM ที่ให้การเข้าถึงโมเดลหลักทั้งหมด รวมถึง Grok และ Llama)
• Self-hosted LLM (โฮสต์บนเซิร์ฟเวอร์ของคุณเอง เช่น ผ่าน Ollama)

เราแนะนำให้ใช้เวอร์ชันโมเดลล่าสุดที่มีอยู่ (เช่น ChatGPT 5.2 แทน 5.0) เนื่องจากโมเดลใหม่กว่ามักให้คุณภาพการแปลที่ดีกว่าอย่างสม่ำเสมอ

คุณสามารถใช้ OpenRouter เพื่อเข้าถึงโมเดล AI ล่าสุด ทันทีที่มีการเปิดตัว

​

พิจารณาการปรับแต่ง AI Translation Prompt

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

ตัวอย่าง:

บล็อกท่องเที่ยวอาจปรับแต่ง prompt ของตนโดยเพิ่มข้อความต่อไปนี้:

Translate to a natural, flowing, easy-to-read, casual blog-style language. Keep original content structure, meaning, and styling (but do adjust sentence structure and style to be relevant to the target language).
 
Lightly improve boring parts - Add curiosity triggers, light humor, and light slang (as fits the target language), like a human travel blogger would write.Copy

คุณสามารถแก้ไข prompt เริ่มต้น หรือสร้าง AI prompt แบบกำหนดเองหลายอัน และเลือกว่าจะใช้อันไหนใน Settings:

​

ตรวจสอบ Gutenberg Blocks ของคุณ

ก่อนแปล คุณต้องระบุว่าใช้บล็อกใดบ้างและตรวจสอบให้แน่ใจว่ารองรับการแปล

Gutenberg blocks ที่รองรับโดยอัตโนมัติ:

• WordPress core blocks ทั้งหมด: Paragraph, Heading, List, Quote, Image, Gallery เป็นต้น
• บล็อกของบุคคลที่สาม: บล็อกจากปลั๊กอิน Yoast SEO, GenerateBlocks, Kadence, Greenshift เป็นต้น

หากคุณใช้บล็อกที่ไม่รองรับซึ่งมีข้อความที่ต้องแปล คุณสามารถ:

• เพิ่ม integration เพื่อแปลบล็อก หรือ
• แทนที่ด้วยบล็อกที่รองรับ (ตัวอย่างเช่น แทนที่บล็อก testimonial แบบกำหนดเองด้วยบล็อกทางเลือกที่รองรับ)

หมายเหตุ: มีบล็อกบางอย่างที่ไม่สามารถแปลได้

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

​

ตรวจสอบ Elementor Widgets ของคุณ

หากคุณใช้ Elementor page builder คุณต้องตรวจสอบว่าใช้ widget ใดบ้างและตรวจสอบให้แน่ใจว่ารองรับการแปล กระบวนการนี้คล้ายกับการตรวจสอบ Gutenberg blocks แต่เฉพาะเจาะจงสำหรับ Elementor widgets

Elementor widget หลักทั้งหมดรองรับโดยอัตโนมัติ

หากคุณมี widgets ที่ไม่รองรับ:

• เพิ่ม integration เพื่อแปล widget หรือ
• แทนที่ด้วย widget ที่รองรับ

​

ตรวจสอบ Bricks Elements ของคุณ

หากคุณใช้ Bricks page builder คุณต้องตรวจสอบว่าใช้ element ใดบ้างและตรวจสอบให้แน่ใจว่ารองรับการแปล กระบวนการนี้คล้ายกับการตรวจสอบ Gutenberg blocks แต่เฉพาะเจาะจงสำหรับ Bricks elements

Bricks element หลักทั้งหมดรองรับโดยอัตโนมัติ

หากคุณมี elements ที่ไม่รองรับ:

• เพิ่ม integration เพื่อแปล element หรือ
• แทนที่ด้วย element ที่รองรับ

​

จัดการรูปภาพที่มีข้อความ

ข้อผิดพลาดที่พบบ่อยในการแปลเว็บไซต์คือการลืมว่ารูปภาพอาจมีข้อความที่ต้องแปลด้วย

เมื่อคุณแปลโพสต์ รูปภาพจะถูกคัดลอกไปยังเวอร์ชันที่แปลแล้ว และข้อมูล metadata ของรูปภาพ (title, alt text, caption) จะถูกแปล แต่ข้อความใดๆ ภายในรูปภาพนั้นยังคงอยู่ในภาษาต้นฉบับ

วิธีที่ง่ายที่สุดในการตรวจสอบรูปภาพของคุณคือเปลี่ยน WordPress Media Library เป็นเลย์เอาต์ Grid ซึ่งช่วยให้คุณสามารถสแกนรูปภาพทั้งหมดด้วยตาได้ในคราวเดียวและระบุรูปที่มีข้อความฝังอยู่ได้อย่างรวดเร็ว

ตัวอย่างเช่น รูปภาพนี้มีข้อความภาษาฮีบรู ทำให้ไม่เหมาะสำหรับภาษาอื่น

ตัวเลือกของคุณ:

1. คงข้อความที่ฝังอยู่ไว้ (หากยังสามารถเข้าใจได้โดยทั่วไป)

   • เหมาะสมเมื่อข้อความอยู่ในภาษาที่เข้าใจได้อย่างแพร่หลาย หรือใช้สัญลักษณ์/ตัวเลขสากล
   • ไม่ต้องดำเนินการเพิ่มเติม

2. ลบข้อความออกจากรูปภาพ

   • ใช้รูปภาพที่ไม่มีข้อความฝังอยู่

3. ใช้ text overlay แทนข้อความที่ฝังอยู่

   • ใช้รูปภาพที่ไม่มีข้อความฝังอยู่
   • วางข้อความทับ (โดยใช้ Gutenberg blocks, Elementor widgets, Bricks elements หรือ CSS) ที่จะถูกแปลโดยอัตโนมัติ

4. สร้างเวอร์ชันรูปภาพที่แปลแล้ว

   • สร้างไฟล์รูปภาพแยกสำหรับแต่ละภาษา
   • แทนที่รูปภาพด้วยตนเองในโพสต์ที่แปลแล้ว

​

จัดการการแปลข้อมูลผู้ใช้เพิ่มเติม

Polylang สามารถจัดการฟิลด์ biography สำหรับโปรไฟล์ผู้ใช้ WordPress ได้ แต่หากคุณมีข้อมูลผู้ใช้เพิ่มเติมที่จัดเก็บใน custom fields (ผ่าน ACF, Meta Box หรือวิธีอื่น) คุณจะต้องใช้วิธีการพิเศษ

หากคุณมีข้อมูลผู้ใช้ที่ต้องการแปล (เช่น ตำแหน่งงาน คุณวุฒิ คำอธิบาย เป็นต้น) คุณจะต้องสร้างฟิลด์แยกสำหรับแต่ละภาษา

1. สร้างฟิลด์แยกสำหรับแต่ละภาษา

   • ใช้ ACF หรือ Meta Box สร้างฟิลด์เช่น:
     • Qualification EN
     • Qualification FR
     • Qualification DE
     • เป็นต้น

2. อัปเดตธีมของคุณเพื่อแสดงฟิลด์ที่ถูกต้อง

   • แก้ไข template ธีมของคุณเพื่อตรวจสอบภาษาปัจจุบัน
   • แสดงฟิลด์ที่เหมาะสมตามภาษาที่ใช้งานอยู่
   • ตัวอย่างโค้ด PHP:

     $current_lang = pll_current_language();
     $qualification = get_field("qualification_{$current_lang}", 'user_' . $user_id);
     echo $qualification;Copy

3. กรอกข้อมูลในฟิลด์ด้วยตนเอง

   • หลังจากแปลเนื้อหาแล้ว อัปเดตฟิลด์โปรไฟล์ผู้ใช้ด้วยตนเอง

​

ข้ามการแปลคำศัพท์ที่ไม่ควรแปล

คำศัพท์บางอย่างไม่ควรถูกแปลเลย เช่น ชื่อแบรนด์ ชื่อเฉพาะ คำศัพท์ทางเทคนิค หรือคำศัพท์เฉพาะทาง

คุณสามารถข้ามการแปลคำศัพท์เหล่านี้ ได้โดยเพิ่มคำสั่งใน custom prompt ของคุณ ตัวอย่างเช่น:

Do not translate the following types of terms:
- Hotel names (e.g., "Grand Hotel", "Beach Resort")
- Restaurant names
- Brand names
- Technical acronyms (API, SEO, CMS, etc.)
 
Keep these terms exactly as they appear in the original text.Copy

​

หลีกเลี่ยง Tag ซ้ำซ้อนข้ามภาษา

เนื้อหาของเราอาจมี tag ที่แสดงถึงแนวคิดเดียวกันในสองภาษาที่แตกต่างกัน เมื่อ tag เหล่านี้ถูกแปล อาจเกิดการซ้ำซ้อนหรือความขัดแย้ง

ตัวอย่างเช่น หากคุณมีเว็บไซต์ภาษาจีนที่แปลเป็นภาษาอังกฤษ และคุณมีทั้ง tag 布宜诺斯艾利斯 (Buenos Aires ในภาษาจีน) และ tag Buenos Aires ในภาษาอังกฤษ เมื่อแปลเป็นภาษาอังกฤษ tag ทั้งสองจะกลายเป็น buenos-aires ซึ่งสร้างสถานการณ์ tag ซ้ำซ้อน

วิธีแก้ไขก่อนแปล:

1. ตรวจสอบ tag ของคุณ

   • ทบทวน tag ทั้งหมดในภาษาต้นฉบับ
   • ระบุ tag ที่อาจซ้ำกับ tag ในภาษาอื่น
   • มองหา tag ที่แสดงถึงแนวคิดเดียวกันแต่ในภาษาต่างกัน

2. รวม tag เข้าด้วยกัน

   • เลือกเวอร์ชันภาษาเดียวที่จะคง (โดยทั่วไปคือภาษาต้นฉบับ)
   • รวมหรือลบ tag ที่ซ้ำซ้อน
   • อัปเดตโพสต์ให้ใช้ tag ที่รวมแล้ว

3. ทำความสะอาดก่อนแปล

   • ตรวจสอบให้แน่ใจว่าเนื้อหาต้นฉบับมีเฉพาะ tag ในภาษาต้นฉบับ
   • ลบ tag ในภาษาเป้าหมายออกจากเนื้อหาต้นฉบับ
   • วิธีนี้ช่วยป้องกันความขัดแย้งในระหว่างการแปล

​

หลีกเลี่ยงชื่อสถานที่ซ้ำซ้อนข้ามภาษา

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

รูปแบบต้นฉบับทั่วไป (ตัวอย่าง):

• ต้นฉบับ (เช่น ในภาษาฮีบรู): פוקט (Pouket) - מדריך לאי היפה — ชื่อท้องถิ่น ตามด้วยการสะกดภาษาอังกฤษหรือสากลในวงเล็บ แล้วตามด้วย subtitle
• แปลแล้ว (เช่น เป็นภาษาอังกฤษ): Pouket (Pouket) - beautiful island guide

หลังจากแปลแล้ว หัวข้ออยู่ในภาษาและ script เดียว ดังนั้นการแสดงผลตามตัวอักษรของโมเดลจะทำให้ชื่อสถานที่เดียวกันปรากฏซ้ำสองครั้ง (เช่น Pouket (Pouket))

วิธีแก้ไข: ปรับ translation prompt ให้เข้มงวดขึ้น

ปรับแต่ง prompt ของคุณ เพื่อให้โมเดลทำให้การเปิดต้น "ชื่อ (ชื่อเดิม)" ที่ซ้ำซ้อนเป็นมาตรฐานเมื่อข้อความในวงเล็บไม่ได้เพิ่มข้อมูลใหม่ ตัวอย่างเช่น เพิ่มคำสั่งเช่น:

If a heading begins with a place name followed by the same translated name in parentheses, remove the duplicate and keep one natural version. Do not remove the parenthesis if the text inside uses a different script, a different spelling, or includes additional descriptive information.Copy

​

ระวัง Slug ของ Tag/Category

หาก slug ของ tag หรือ category อยู่ในภาษาเป้าหมายอยู่แล้ว คุณอาจคิดว่าไม่มีอะไรต้องแปล

โดยทั่วไปนั้นก็ไม่เป็นปัญหา แต่มีข้อควรระวังสำหรับ Polylang free (ไม่ใช่ Pro)

ด้วย Polylang Pro term ที่แปลแล้วสามารถใช้ slug เดิมซ้ำข้ามภาษาได้ แต่ด้วยเวอร์ชันฟรี WordPress บังคับให้ slug ไม่ซ้ำกันทั้งหมด ดังนั้น slug ของ term ที่แปลแล้วจะได้รับ suffix -2 ต่อท้ายโดยอัตโนมัติ

ตัวอย่างเช่น category ที่มี slug travels_and_attractions ในภาษาฮีบรู เมื่อแปลเป็นภาษาอังกฤษ จะกลายเป็น travels_and_attractions-2 แทนที่จะคง slug เดิมไว้

หากสิ่งนี้ส่งผลต่อ URL หรือ SEO ของคุณ คุณจะต้องแก้ไข slug ด้วยตนเองหลังจากการแปล หรืออัปเกรดเป็น Polylang Pro เพื่อให้สามารถใช้ slug ซ้ำข้ามภาษาได้

​

ตรวจสอบให้แน่ใจว่า Embed ของคุณอยู่ในภาษาที่ยอมรับได้

หากคุณฝัง third-party content เช่น Google Maps, social media widget หรือ iframe จากแพลตฟอร์มอื่น ตรวจสอบให้แน่ใจว่า embed แสดงผลในภาษาเป้าหมาย

ตัวอย่างเช่น Google Maps embed ที่กำหนดค่าสำหรับภาษาฮีบรูจะยังคงแสดง label ภาษาฮีบรู ชื่อถนน และ UI แม้ว่าคุณจะแปลส่วนอื่นๆ ของหน้าเป็นภาษาอังกฤษแล้ว ในกรณีนั้น คุณอาจต้องการใช้ embed ที่ไม่ขึ้นกับภาษา

เช่นเดียวกันกับแพลตฟอร์มหรือบริการใดก็ตามที่สร้าง embed เฉพาะภาษา (เช่น YouTube chapters, review widget, booking form) ตรวจสอบ embed แต่ละอันเสมอหลังจากการแปล

​

ตรวจสอบให้แน่ใจว่าไม่มีการจัดรูปแบบเฉพาะภาษาในเนื้อหาต้นฉบับ

เนื้อหาโพสต์ที่เขียนสำหรับภาษาเฉพาะ โดยเฉพาะภาษา RTL เช่น ภาษาฮีบรูหรืออาหรับ อาจมี inline direction และ language attribute ที่ใส่ไว้โดยตรงในองค์ประกอบ HTML เมื่อเนื้อหานั้นถูกแปลเป็นภาษาอื่น รูปแบบที่ hard-code ไว้เหล่านั้นจะยังคงอยู่และทำให้เลย์เอาต์เสียหาย

ต้นเหตุที่พบบ่อยในเนื้อหาต้นฉบับ RTL:

• <div dir="rtl" lang="he"> — บังคับทิศทาง RTL และระบุภาษาเป็นฮีบรูสำหรับทั้งส่วน
• <p dir="rtl"> — บังคับการจัดตำแหน่ง RTL สำหรับย่อหน้าแต่ละอัน
• <h2 style="text-align: right;"> — hard-code การจัดตำแหน่งชิดขวาสำหรับ heading

เมื่อเนื้อหานี้ถูกแปลเป็นภาษาอังกฤษ (หรือภาษา LTR ใดก็ตาม) ข้อความจะกลายเป็นภาษาอังกฤษแต่เลย์เอาต์ยังคงแสดงผลจากขวาไปซ้าย ส่งผลให้ heading ไม่ตรงแนว การไหลของข้อความย้อนกลับ และการจัดรูปแบบเสียหาย

ก่อนแปล ตรวจสอบเนื้อหาต้นฉบับของคุณสำหรับ attribute เหล่านี้และลบออก ให้ theme และการตั้งค่าภาษา/locale ของ WordPress ควบคุมทิศทางและการจัดตำแหน่งโดยรวม แทนที่จะฝังไว้ใน content block แต่ละอัน

​

จัดการ Elementor Theme Builder Templates

หากคุณใช้ Elementor's Theme Builder เพื่อสร้าง template ระดับ global (header, footer, single post template, archive template เป็นต้น) สิ่งสำคัญคือต้องเข้าใจว่า template เหล่านี้ถูกจัดการอย่างไรในระหว่างการแปล

สิ่งที่ได้รับการแปล:

• เมนู: รายการเมนูจะถูกแทนที่ด้วยเวอร์ชันเมนูที่แปลแล้ว
• เนื้อหา dynamic: เนื้อหาที่ดึงมาจากโพสต์/หน้าจะได้รับการแปล (เนื่องจากเนื้อหาต้นทางถูกแปลแล้ว)

สิ่งที่ไม่ได้รับการแปล:

• ข้อความที่ hard-code: ข้อความใดๆ ที่เพิ่มโดยตรงใน template (ไม่ได้มาจาก dynamic content) จะไม่ถูกแปล
• ข้อความใน widget: ข้อความใน widget เช่น heading, paragraph, button เป็นต้น จะยังคงอยู่ในภาษาต้นฉบับ
• Custom HTML: HTML หรือ code block แบบกำหนดเองใดๆ จะยังไม่ถูกแปล

ตัวอย่าง:

Elementor header template นี้มีข้อความที่ hard-code ("Our Phone Number:"):

วิธีแก้ไข:

ออกแบบ template ให้ใช้เฉพาะ:

• เมนู (ซึ่งถูกแทนที่โดยอัตโนมัติ)
• รูปภาพ (ซึ่งไม่ขึ้นกับภาษา)
• เนื้อหา dynamic (ซึ่งมาจากโพสต์ที่แปลแล้ว)
• หลีกเลี่ยงการเพิ่มข้อความ heading หรือคำอธิบายที่ hard-code โดยตรงใน template

วิธีนี้ช่วยให้แน่ใจว่า global element ของเว็บไซต์ (header, footer เป็นต้น) ทำงานได้อย่างถูกต้องในทุกภาษา

​

กำหนดค่า Advanced Custom Fields (ACF)

หากคุณใช้ Advanced Custom Fields (ACF) คุณจำเป็นต้องกำหนดค่าว่าแต่ละฟิลด์ควรจัดการอย่างไรในระหว่างการแปล ฟิลด์ ACF สามารถมีเนื้อหาได้หลายประเภท และแต่ละประเภทอาจต้องการการจัดการที่แตกต่างกัน

ภายใต้ส่วน Gato Translate ฟิลด์ ACF สามารถตั้งค่าเป็นหนึ่งในตัวเลือกเหล่านี้:

1. (ไม่ดำเนินการใดๆ): ฟิลด์จะถูกข้ามในการแปลหรือซิงค์

2. Translate: เนื้อหาของฟิลด์จะถูกแปลเป็นภาษาเป้าหมาย

   • ใช้สำหรับ: ฟิลด์ข้อความ, ฟิลด์พื้นที่ข้อความ, ฟิลด์ WYSIWYG และฟิลด์ใดๆ ที่มีข้อความที่สามารถแปลได้

3. Copy: ค่าฟิลด์จะถูกคัดลอกตามที่เป็นไปยังการแปล (ไม่แปล)

   • ใช้สำหรับ: ตัวเลข, วันที่, ช่องทำเครื่องหมาย, ฟิลด์ true/false และฟิลด์ใดๆ ที่ไม่ควรแปล

4. Translate Reference: ฟิลด์อ้างอิงถึงเอนทิตีอื่น (โพสต์, หน้า, ผู้ใช้ ฯลฯ) และการอ้างอิงจะถูกอัปเดตให้ชี้ไปยังเวอร์ชันที่แปลแล้ว

   • ใช้สำหรับ: ฟิลด์ Post Object, Page Link, Relationship, User และ Taxonomy

หากคุณใช้ Polylang Pro คุณต้องปิดใช้งานคุณลักษณะการแปล ACF ของมัน เพื่อให้ Gato AI Translations จัดการการแปลแทน

​

กำหนดค่า Meta Box

หากคุณใช้ Meta Box (ปลั๊กอินฟิลด์แบบกำหนดเองที่ได้รับความนิยมอีกตัว) กระบวนการกำหนดค่าจะคล้ายกับ ACF ฟิลด์ Meta Box ก็ต้องกำหนดค่าสำหรับการแปล, การคัดลอก หรือการแปลการอ้างอิงเช่นกัน

ภายใต้ส่วน Gato Translate ฟิลด์ Meta Box สามารถตั้งค่าเป็นหนึ่งในตัวเลือกเหล่านี้:

1. (ไม่ดำเนินการใดๆ): ฟิลด์จะถูกข้ามในการแปลหรือซิงค์
2. Translate: เนื้อหาของฟิลด์จะถูกแปล
3. Copy: ค่าฟิลด์จะถูกคัดลอกตามที่เป็น
4. Translate Reference: การอ้างอิงของฟิลด์จะถูกอัปเดตให้ชี้ไปยังเอนทิตีที่แปลแล้ว

คุณต้องปิดใช้งานคุณลักษณะการแปล Meta Box ของ Polylang เพื่อให้ Gato AI Translations จัดการการแปลแทน

​

กำหนดค่า Custom Meta Fields

นอกเหนือจาก ACF, Meta Box และปลั๊กอิน SEO ไซต์ของคุณอาจมี custom meta fields อื่นๆ จาก:

• โค้ดแบบกำหนดเอง
• ปลั๊กอินอื่นๆ
• WordPress custom fields (metabox Custom Fields พื้นฐาน)

meta fields เหล่านี้จำเป็นต้องกำหนดค่าด้วยตนเองในการตั้งค่าปลั๊กอิน

การระบุ custom meta keys:

1. ส่งออกเนื้อหาของคุณ

   • ไปที่ Tools > Export ใน WordPress
   • ส่งออกเนื้อหาทุกประเภทที่คุณวางแผนจะแปล
   • ซึ่งจะสร้างไฟล์ XML พร้อมเนื้อหาและ metadata ทั้งหมดของคุณ

2. วิเคราะห์ไฟล์ส่งออก

   • เปิดไฟล์ XML ในโปรแกรมแก้ไขข้อความ
   • ค้นหาแท็ก <wp:postmeta>
   • แสดงรายการ meta keys ที่ไม่ซ้ำกันทั้งหมด

3. กรองฟิลด์ที่รู้จักออก

   • ลบฟิลด์ ACF (โดยทั่วไปมีคำนำหน้าด้วยชื่อกลุ่มฟิลด์ของคุณ)
   • ลบฟิลด์ Meta Box
   • ลบฟิลด์หลักของ WordPress (เช่น _edit_last, _wp_old_slug, _thumbnail_id)
   • ลบฟิลด์ปลั๊กอิน SEO (หากใช้ปลั๊กอิน SEO ที่รองรับ)

4. ระบุสิ่งที่เหลืออยู่

   • เหล่านี้คือ custom meta fields ของคุณ
   • กำหนดว่าแต่ละฟิลด์มีอะไรและควรจัดการอย่างไร

การกำหนดความต้องการในการแปล:

สำหรับ custom meta field แต่ละอัน ให้กำหนด:

• Translate: มีข้อความที่สามารถแปลได้ (ชื่อเรื่อง, คำอธิบาย, เนื้อหา)
• Copy: มีข้อมูลที่ไม่ควรแปล (IDs, ตัวเลข, การตั้งค่า)
• Translate Reference: มี entity IDs ที่ควรชี้ไปยังเวอร์ชันที่แปลแล้ว

การกำหนดค่าในปลั๊กอิน:

1. ไปที่การตั้งค่า ภายใต้แท็บ Meta Configuration
2. เลือกตัวเลือกการแปล (Translate/Copy/Translate Reference)
3. เพิ่มชื่อ custom meta key โดยใช้การจับคู่แบบตรงทั้งหมดหรือรูปแบบ regex

​

ดำเนินการกระบวนการแปล

เมื่อการเตรียมการทั้งหมดเสร็จสมบูรณ์แล้ว ถึงเวลาดำเนินการแปล

​

ทดสอบกระบวนการก่อน

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

นี่คือขั้นตอนการทดสอบที่แนะนำ:

1. เริ่มด้วยโพสต์เดียวและหนึ่งภาษา

   • เลือกโพสต์ตัวแทนที่มีเนื้อหาหลายประเภท (ข้อความ, รูปภาพ, ลิงก์ ฯลฯ)
   • แปลเป็นภาษาเป้าหมายเพียงภาษาเดียวที่คุณเข้าใจดี
   • ตรวจสอบการแปลอย่างละเอียด: ตรวจทุก block ทุกลิงก์ ทุกรูปภาพ และทุกชิ้นส่วน metadata
   • หากคุณพบปัญหาใดๆ (เช่น block ไม่ได้แปล, ลิงก์ไม่ถูกแทนที่, การจัดรูปแบบเสียหาย) ให้แก้ไขก่อนดำเนินการต่อ ปัญหาเดียวกันจะถูกทำซ้ำสำหรับทุกภาษาหากคุณไม่จัดการกับมันตอนนี้

2. ขยายไปยังโพสต์เพิ่มเติมอีกสองสามรายการ

   • เมื่อการแปลแรกสมบูรณ์แบบแล้ว แปล 3-5 โพสต์เพิ่มเติมเป็นภาษาเดียวกัน
   • ตรวจสอบแต่ละรายการอย่างละเอียด
   • ช่วยให้คุณระบุรูปแบบหรือปัญหาที่เกิดขึ้นซ้ำๆ

3. ทดสอบกับภาษาเพิ่มเติม

   • หากคุณแปลเป็นหลายภาษา ทดสอบกับอีกหนึ่งภาษาเพื่อให้แน่ใจว่าทุกอย่างทำงานได้กับคู่ภาษาที่แตกต่างกัน

4. เฉพาะเมื่อนั้นจึงดำเนินการแปลเป็นกลุ่ม

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

วิธีการแบบค่อยเป็นค่อยไปนี้ช่วยให้มั่นใจว่าปัญหาการกำหนดค่าหรือปัญหาเนื้อหาถูกตรวจจับตั้งแต่เนิ่นๆ เมื่อยังง่ายต่อการแก้ไข

​

ลำดับการแปล

ลำดับที่คุณแปลประเภทเนื้อหาต่างๆ มีความสำคัญ โดยเฉพาะเมื่อเนื้อหาอ้างอิงถึงเนื้อหาอื่น

แปลเนื้อหาในลำดับเฉพาะนี้เพื่อหลีกเลี่ยงปัญหาการอ้างอิง:

1. ผู้ใช้

   • คำอธิบายผู้ใช้อาจรวมอยู่ใน blocks

2. Taxonomies (แท็ก/หมวดหมู่)

   • แท็กและหมวดหมู่ (และ custom taxonomies) มักถูกอ้างอิงโดยโพสต์ ดังนั้นจำเป็นต้องมีอยู่ก่อนโพสต์ถูกแปล

3. สื่อ

   • รายการสื่อ (รูปภาพ, วิดีโอ, เอกสาร) ถูกอ้างอิงโดยโพสต์เป็นรูปภาพเด่นหรือรูปภาพแกลเลอรี ดังนั้นให้แปลก่อนโพสต์

4. Custom Post Types

   • แปลโพสต์, หน้า และ CPT อื่นๆ
   • สำคัญ: หาก CPT หนึ่งอ้างอิงถึงอีก CPT หนึ่ง ให้แปลตามลำดับการพึ่งพาแบบย้อนกลับ
   • ตัวอย่าง: หากโพสต์ใช้ Reusable Blocks ให้แปล Reusable Blocks ก่อน แล้วจึงแปล Posts

5. เมนู

   • แปลเมนูเป็นลำดับสุดท้าย เนื่องจากอ้างอิงถึงโพสต์, หน้า และหมวดหมู่

​

ตัดสินใจว่าจะแปล slugs หรือไม่

การแปล slugs ของโพสต์และ taxonomy เป็นภาษาเป้าหมายมักเป็นที่ต้องการสำหรับภาษาสคริปต์ละติน (เช่น ฝรั่งเศส, เยอรมัน, สเปน): เส้นทางยังคงอ่านได้และคุณสามารถสะท้อนคำหลักที่แปลแล้วใน URL ได้

สำหรับสคริปต์ที่ไม่ใช่ละติน—ฮีบรู, ญี่ปุ่น, จีน และภาษาที่คล้ายกัน—slugs ที่แปลแล้วมักกลายเป็นความยุ่งเหยิง: การทับศัพท์ที่ไม่เป็นธรรมชาติ, ส่วนที่ยาวมาก, การเข้ารหัส percent หรือ URLs ที่แชร์และเปรียบเทียบได้ยาก หลายทีมเก็บ slugs ในละติน (หรือภาษาต้นทาง) สำหรับภาษาเหล่านั้นและพึ่งพา title ที่แปลแล้วสำหรับชื่อที่มองเห็นได้และแปลเป็นภาษาท้องถิ่น

ปฏิบัติต่อการแปล slug เป็นนโยบายต่อภาษาเป้าหมาย ไม่ใช่สวิตช์เปิด/ปิดเดียวสำหรับทั้งไซต์:

1. แบ่งภาษาออกเป็นกลุ่ม — เช่น "แปล slugs" สำหรับเป้าหมายละติน vs "ไม่แปล slugs" สำหรับจีน, ญี่ปุ่น, ฮีบรู ฯลฯ
2. รันการแปลแบบกลุ่มแยกกัน — แปลเป็นกลุ่มหนึ่งโดยเปิดใช้งานการแปล slug แล้วรันชุดอื่นเป็นกลุ่มอีกกลุ่มโดยปิดการแปล slug
3. กำหนดค่าแต่ละชุด ผ่าน Gato Translate (Custom) (ครอบคลุมภายใต้ วิธีดำเนินการแปล ด้านล่าง): ปิดใช้งานตัวเลือกเช่น Translate custom post slugs? และ Translate tag and category slugs? สำหรับชุดที่คุณต้องการเก็บ slugs ไม่เปลี่ยนแปลง มุ่งหวังหนึ่งนโยบายต่อการรัน (เช่น หนึ่งภาษาหรือหนึ่งกลุ่มภาษาที่มีกฎเดียวกัน) เพื่อให้การตั้งค่าตรงกับผลลัพธ์ที่คาดหวัง

สำหรับขั้นตอนการทำงานแบบสคริปต์หรือทำซ้ำได้ WP-CLI รองรับ --translate-slugs=true หรือ --translate-slugs=false ต่อการเรียกใช้

​

การแปลสองรอบ

หากคุณเปิดใช้งาน การแทนที่ลิงก์ภายใน หรือ การแปลการอ้างอิง entity คุณอาจต้องแปลสองรอบ:

รอบที่ 1: แปลคุณสมบัติเท่านั้น

1. กำหนดค่าการแปลให้ยกเว้น content และ meta นั่นคือแปล properties เท่านั้น (title/name และ slug)
2. ดำเนินการแปล

หลังจากดำเนินการรอบแรก โพสต์ที่แปลแล้วจะถูกสร้างขึ้นพร้อม URLs และ IDs ที่แปลแล้ว ทำให้ URL ลิงก์ภายในและ entity reference IDs สามารถแก้ไขเป็นภาษาเป้าหมายได้

รอบที่ 2: แปล Content และ Meta เท่านั้น

1. กำหนดค่าการแปลให้ แปล content และ meta เท่านั้น (นั่นคือยกเว้น properties)
2. ดำเนินการแปลอีกครั้ง

หลังจากดำเนินการรอบที่สอง เนื้อหาและ meta ที่เหลือจะถูกแปล และ URL ลิงก์ภายในและ entity reference IDs จะถูกแทนที่ด้วยเวอร์ชันที่แปลแล้ว

​

วิธีดำเนินการแปล

ตัวเลือกที่ 1: WordPress Admin (Bulk Actions)

1. ไปที่รายการเนื้อหา (Posts, Pages, Media ฯลฯ)
2. เลือกรายการที่คุณต้องการแปล
3. เลือก Gato Translate จากเมนูดรอปดาวน์ bulk actions
4. คลิก Apply

ทางเลือก: Gato Translate (Custom)

สำหรับการควบคุมที่มากขึ้น ใช้ Gato Translate (Custom) ซึ่งช่วยให้คุณแทนที่การตั้งค่าสำหรับการรันการแปลนั้นโดยเฉพาะ:

ซึ่งจะเปิดหน้าการตั้งค่าแบบกำหนดเองที่คุณสามารถระบุตัวเลือกเฉพาะสำหรับการรันการแปลนั้น:

ตัวเลือกที่ 2: WP-CLI (สำหรับชุดขนาดใหญ่)

สำหรับเว็บไซต์ขนาดใหญ่ที่มีรายการหลายร้อยหรือหลายพันรายการ WP-CLI เป็นทางเลือกที่สะดวก

คุณสามารถรันการแปลเป็นชุดผ่าน command line แล้วคุณสามารถดำเนินการแปลในพื้นหลังได้ ในขณะที่คุณกำลังทำงานอื่น

​

การตรวจสอบ logs การแปล

เมื่อการแปลล้มเหลว (เนื่องจาก API ออฟไลน์, ใช้ API credits หมด ฯลฯ) หรือสร้างคำเตือน คุณจะเห็นป้ายแจ้งเตือนในเมนูปลั๊กอิน:

ตรวจสอบlogs การแปล เพื่อทำความเข้าใจว่าเกิดอะไรขึ้น:

1. ไปที่รายการเมนู Logs ในเมนูปลั๊กอิน
2. ตรวจสอบข้อผิดพลาดหรือคำเตือนใดๆ
3. แก้ไขปัญหาก่อนดำเนินการต่อ

​

การรันการแปลที่ล้มเหลวใหม่อีกครั้ง

เมื่อใดก็ตามที่การแปลล้มเหลว คุณสามารถกระตุ้นการแปลรายการนั้นและภาษานั้นใหม่อีกครั้ง และหลีกเลี่ยงการใช้ API credits สำหรับการแปลที่สำเร็จแล้ว

การแปลที่ล้มเหลวจะถูกไฮไลต์ด้วยพื้นหลังสีเหลืองบนไอคอนแก้ไข Polylang:

คุณสามารถกรองเพื่อแสดงเฉพาะรายการที่การแปลล้มเหลว:

เพื่อแปลซ้ำเฉพาะรายการที่ล้มเหลว ให้ใช้ bulk action Gato Translate (Custom) พร้อมตัวเลือก Process failed translations only:

​

ตรวจสอบคุณภาพและความสมบูรณ์ของการแปล

หลังจากแปลเนื้อหาแล้ว สิ่งสำคัญคือต้องตรวจสอบว่าการแปลสำเร็จและมีคุณภาพดี อย่าสันนิษฐานว่าทุกอย่างสมบูรณ์แบบ—ใช้เวลาตรวจสอบให้ถี่ถ้วน

การตรวจสอบในหน้าแก้ไข:

เปิดโพสต์ที่แปลแล้วในตัวแก้ไข WordPress และตรวจสอบ:

1. การแปลเนื้อหา

   • ข้อความทั้งหมดถูกแปลแล้วหรือไม่? (ไม่ใช่แค่หัวเรื่อง)
   • บล็อก/วิดเจ็ต/องค์ประกอบทั้งหมดถูกแปลแล้วหรือไม่?
   • ตรวจสอบบล็อก Gutenberg, วิดเจ็ต Elementor หรือองค์ประกอบ Bricks
   • ตรวจสอบว่าการจัดรูปแบบยังคงอยู่

2. ฟิลด์กำหนดเอง

   • ฟิลด์ ACF ถูกแปล/คัดลอก/อ้างอิงอย่างถูกต้องหรือไม่?
   • ฟิลด์ Meta Box ได้รับการจัดการอย่างเหมาะสมหรือไม่?
   • ฟิลด์ meta กำหนดเองได้รับการตั้งค่าอย่างถูกต้องหรือไม่?

3. ข้อมูลเมตา SEO

   • ตรวจสอบว่าชื่อ meta ถูกแปลแล้ว
   • ตรวจสอบว่าคำอธิบาย meta ถูกแปลแล้ว
   • ยืนยันว่าแท็ก Open Graph ถูกแปลแล้ว
   • ตรวจสอบฟิลด์ของปลั๊กอิน SEO อื่น ๆ

4. สื่อ

   • รูปภาพเด่นถูกตั้งค่าอย่างถูกต้องหรือไม่?
   • รูปภาพในเนื้อหาชี้ไปยังเวอร์ชันที่แปลแล้วหรือไม่ (ถ้ามี)?
   • ข้อความแสดงแทนรูปภาพถูกแปลแล้วหรือไม่?

5. ลิงก์

   • ลิงก์ภายในชี้ไปยังเวอร์ชันที่แปลแล้วหรือไม่?
   • ลิงก์ภายนอกยังคงถูกต้องหรือไม่?
   • ลิงก์หมวดหมู่/แท็กทำงานได้หรือไม่?

การตรวจสอบในหน้าเว็บ:

ดูโพสต์ที่แปลแล้วในเบราว์เซอร์และตรวจสอบ:

1. รูปลักษณ์ภายนอก

   • หน้าเว็บดูถูกต้องหรือไม่?
   • โครงร่างยังคงอยู่หรือไม่?
   • รูปภาพแสดงอย่างถูกต้องหรือไม่?
   • สไตล์ถูกต้องหรือไม่?

2. การใช้เทมเพลต

   • มีการใช้เทมเพลตที่ถูกต้องหรือไม่?
   • ส่วนหัว/ส่วนท้ายแสดงอย่างถูกต้องหรือไม่?
   • แถบข้าง/วิดเจ็ตแสดงอยู่หรือไม่?
   • เมนูแสดงเวอร์ชันที่แปลแล้วหรือไม่?

3. ฟังก์ชันการทำงาน

   • ลิงก์ทั้งหมดทำงานได้หรือไม่?
   • ฟอร์มทำงานได้หรือไม่?
   • องค์ประกอบแบบโต้ตอบทำงานได้หรือไม่?
   • การนำทางถูกต้องหรือไม่?

4. องค์ประกอบเฉพาะภาษา

   • สำหรับภาษาที่อ่านจากขวาไปซ้าย โครงร่างถูกต้องหรือไม่?
   • แบบอักษรแสดงผลอย่างถูกต้องหรือไม่?
   • ทิศทางของข้อความถูกต้องหรือไม่?

คุณภาพการแปล:

การแปลด้วย AI สมัยใหม่โดยทั่วไปดีมาก แต่คุณควรตรวจสอบอยู่ดี:

1. ภาษาที่คุณเข้าใจ

   • อ่านการแปลในภาษาที่คุณรู้
   • ตรวจสอบความถูกต้อง น้ำเสียง และสไตล์
   • ตรวจสอบว่าคำศัพท์ทางเทคนิคถูกต้อง
   • ตรวจสอบให้แน่ใจว่าเสียงของแบรนด์ยังคงอยู่

2. ภาษาที่คุณไม่เข้าใจ

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

3. เนื้อหาเฉพาะด้าน

   • เนื้อหาทางเทคนิคอาจต้องให้ผู้เชี่ยวชาญตรวจสอบ
   • เนื้อหาทางกฎหมาย/การแพทย์ควรได้รับการตรวจสอบโดยผู้เชี่ยวชาญ
   • เนื้อหาด้านการตลาดอาจต้องปรับเสียงของแบรนด์

​

ซ่อมแซมบล็อก "เนื้อหาไม่ถูกต้อง"

เมื่อแปล HTML ขนาดใหญ่ที่มีแท็กและแอตทริบิวต์จำนวนมาก บริการ AI บางครั้งอาจคืนค่าการตอบสนองที่ทำให้ผลลัพธ์ของบล็อกผิดพลาด

ตัวอย่างเช่น เมื่อแปลบล็อก core/paragraph ที่มี HTML blob ขนาดใหญ่มากโดยใช้ ChatGPT 5.0 mini เช่นนี้:

<!-- wp:paragraph -->
<p>
  Pédagogie: 
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark></mark></mark><strong><br></strong>Support : 
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark></mark></mark><br>Coûts : 
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark></mark></mark><br>Débouchés : 
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
  <mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark>
</p>
<!-- /wp:paragraph -->Copy

...การตอบสนองอาจแนะนำแท็ก <mark> เพิ่มเติมที่ไม่ได้มีอยู่ในเนื้อหาต้นฉบับ:

<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★
+<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">Copy

เมื่อแก้ไขโพสต์ในตัวแก้ไข WordPress บล็อกนั้นอาจไม่สามารถแสดงผลได้และแสดงข้อความ "Block contains unexpected or invalid content" แทน:

การคลิก Attempt recovery มีแนวโน้มสูงที่จะแก้ปัญหาได้

​

แก้ไขปัญหาข้อผิดพลาดข้อมูลเสียหาย

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

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

ทำความเข้าใจกับข้อผิดพลาด:

เมื่อคุณเห็นข้อผิดพลาดแบบนี้ในบันทึก:

2025-10-25T03:40:38+00:00 Error [Query "create-missing-translation-media"] Execution with errors: 🔴 Object with ID '26061' (of type 'GenericCustomPost') cannot be loaded. Please check if referencing this ID is stale data (i.e. still stored on the WordPress database, but pointing to a non-existing object) and, if so, remove it or fix it.Copy

หมายความว่า:

• เนื้อหาอ้างอิงเอนทิตี (โพสต์ หน้า สื่อ ฯลฯ) ที่มี ID 26061
• เอนทิตีนั้นไม่มีอยู่ในฐานข้อมูลอีกต่อไป
• ปลั๊กอินไม่สามารถแปลได้เพราะไม่สามารถแก้ไขการอ้างอิงได้

วิธีแก้ไข:

วิธีที่ 1: WordPress Editor (ง่ายที่สุด)

1. เปิดโพสต์/รายการที่แปลไม่ได้
2. ระบุการอ้างอิงที่เสียหาย (ตรวจสอบฟิลด์กำหนดเอง ความสัมพันธ์ ฯลฯ)
3. ลบหรือแก้ไขการอ้างอิง
4. บันทึกโพสต์
5. ลองแปลอีกครั้ง

วิธีที่ 2: ทำความสะอาดฐานข้อมูล

หากคุณไม่สามารถแก้ไขผ่านตัวแก้ไขได้:

1. ระบุว่าฟิลด์ใดมีการอ้างอิงที่ผิดพลาด
2. ใช้เครื่องมือฐานข้อมูลหรือปลั๊กอินเพื่อลบข้อมูลเก่า
3. ระวัง—สำรองข้อมูลทุกครั้งก่อนทำการเปลี่ยนแปลงฐานข้อมูล

วิธีที่ 3: Gato GraphQL (ขั้นสูง)

เนื่องจาก Gato AI Translations for Polylang ใช้ Gato GraphQL อยู่เบื้องหลัง คุณสามารถรัน GraphQL queries เพื่อแก้ไขข้อมูลเสียหายโดยทางโปรแกรม:

1. ขั้นแรก ดึง ID ของรายการที่มีปัญหาโดยใช้ GraphQL query

2. จากนั้นแก้ไขปัญหาโดยใช้ mutation ตัวอย่างเช่น เพื่อลบการอ้างอิงแม่จากรายการสื่อ:

mutation {
  updateMediaItem( input: { id: 26066, customPostID: null } ) {
    status
    errors {
      __typename
      ...on GenericErrorPayload {
        message
      }
    }
  }
}Copy

หากคุณไม่สามารถแก้ไขได้:

หากไม่สามารถทำความสะอาดข้อมูลเสียหายได้ คุณอาจต้อง:

• สร้างโพสต์/รายการใหม่ตั้งแต่ต้น
• ส่งออกเนื้อหา ทำความสะอาด และนำเข้าใหม่
• ติดต่อฝ่ายสนับสนุนสำหรับกรณีที่ซับซ้อน

​

รวมรายการที่แปลแล้วเข้าในการตั้งค่าเว็บไซต์

หลังจากแปลเนื้อหาแล้ว รายการที่แปลใหม่อาจต้องถูกรวมเข้าในการตั้งค่าเว็บไซต์

​

อัปเดต ACF Field Groups

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

หลังจากแปลแล้ว อัปเดตการกำหนด ACF Field Group ของคุณเพื่อรวมเวอร์ชันที่แปลแล้ว:

1. ไปที่รายการเมนู Field Groups ในเมนูปลั๊กอิน ACF
2. แก้ไข field group ที่ใช้กับเอนทิตีที่เฉพาะเจาะจง
3. ใน Location Rules เพิ่มเวอร์ชันที่แปลแล้ว
4. บันทึก field group

ตัวอย่าง:

field group ใช้กับโพสต์เฉพาะ "Hello World" ในภาษาต้นฉบับ:

หลังจากแปลโพสต์แล้ว เวอร์ชันที่แปลแล้ว ("Hola Mundo" ในภาษาสเปน และ "你好世界" ในภาษาจีน) ต้องถูกกำหนดให้กับ field group เดิมด้วย:

​

เสร็จเรียบร้อยแล้ว!

คุณได้ทำกระบวนการแปลเสร็จสมบูรณ์แล้ว ยินดีด้วย! 👏

​

บทสรุป

คู่มือฉบับสมบูรณ์นี้ควรช่วยให้คุณแปลเว็บไซต์ WordPress ได้สำเร็จ หากคุณต้องการข้อมูลเพิ่มเติม ตรวจสอบได้ที่เอกสารของ Gato AI Translations for Polylang