PolyLingo กับ DeepL API: อันไหนรักษา JSON และ Markdown ได้ดีกว่า?

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

คำถามที่โพสต์นี้ตอบคือคำถามที่แคบกว่า: DeepL API ทำงานอย่างไรเมื่อเนื้อหาของคุณมีโครงสร้าง? เมื่อคุณต้องแปลไฟล์ JSON locale โดยไม่แตะต้องคีย์ หรือโพสต์บล็อก Markdown โดยไม่ทำลายไวยากรณ์ หรือหน้า HTML โดยไม่ทำลายแอตทริบิวต์? และมันเปรียบเทียบกับ PolyLingo สำหรับกรณีการใช้งานเฉพาะนั้นอย่างไร?

วิธีการสร้าง DeepL API

DeepL text translation API รับข้อความธรรมดา นั่นคือรูปแบบอินพุตพื้นฐานของมัน คำขอแต่ละครั้งรับได้สูงสุด 50 สตริงข้อความและจะแปลแยกกันโดยไม่มีบริบทร่วมระหว่างกัน สามารถระบุภาษาปลายทางได้เพียงภาษาเดียวต่อคำขอ หากคุณต้องการห้าภาษา คุณต้องส่งคำขอห้าครั้ง

DeepL รองรับการแปลเอกสารสำหรับรูปแบบเช่น PDF, Word, PowerPoint และ HTML แต่จะผ่านเอนด์พอยต์เอกสารแยกต่างหากที่มีขั้นตอนต่างกัน: อัปโหลดไฟล์, ตรวจสอบสถานะจนเสร็จ, ดาวน์โหลดผลลัพธ์ มันถูกออกแบบมาสำหรับเอกสารสำนักงาน ไม่ใช่สำหรับสายงานเนื้อหาแบบโปรแกรม

สำหรับ HTML โดยเฉพาะ มีพารามิเตอร์ tag_handling ที่คุณสามารถตั้งค่าเป็น html ซึ่งบอก DeepL ให้ปฏิบัติต่ออินพุตเป็น HTML และพยายามรักษาแท็กไว้ ซึ่งทำงานได้ดีพอสมควรสำหรับมาร์กอัปง่าย ๆ แต่เป็นแฟล็กที่ต้องตั้งค่าเองและไม่ครอบคลุมถึง JSON หรือ Markdown

สำหรับ JSON ไม่มีการสนับสนุนโดยตรง DeepL text endpoint ไม่รู้จักคีย์ JSON หากคุณส่งอ็อบเจ็กต์ JSON ที่ถูกแปลงเป็นสตริง มันจะแปลเนื้อหาเป็นสตริงและไม่มีการรับประกันว่าคีย์ โครงสร้าง หรือค่าที่ไม่ใช่สตริงจะยังคงอยู่ครบถ้วน ไลบรารี R babeldown ซึ่งห่อหุ้ม DeepL สำหรับเนื้อหา Markdown มีกรณีที่บันทึกไว้ว่า DeepL สับสนเครื่องหมายวรรคตอนภายในลิงก์ Markdown และการจัดรูปแบบ ซึ่งเป็นข้อจำกัดที่ทราบของการส่งข้อความที่มีโครงสร้างผ่านเครื่องแปลข้อความธรรมดา

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

จุดที่ความแตกต่างปรากฏในทางปฏิบัติ

ความแตกต่างจะเห็นได้ชัดเมื่อเนื้อหาของคุณไม่ใช่ข้อความธรรมดา

ลองพิจารณาไฟล์ locale ของ Next.js มาตรฐาน:

{
  "nav": {
    "home": "Home",
    "about": "About us",
    "contact": "Get in touch"
  },
  "hero": {
    "title": "Welcome to our platform",
    "subtitle": "Everything you need in one place"
  }
}

หากจะแปลไฟล์นี้ด้วย DeepL API เป็นห้าภาษา คุณจะต้อง:

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

ด้วย PolyLingo คุณส่งอ็อบเจ็กต์ตามเดิมพร้อม format: "json" และรับกลับเวอร์ชันแปลของโครงสร้างทั้งหมดสำหรับทุกภาษาปลายทางในคำตอบเดียว คีย์ไม่ถูกแตะต้อง การซ้อนกันถูกเก็บไว้ ค่าที่ไม่ใช่สตริงไม่ถูกเปลี่ยนแปลง ผลลัพธ์สามารถนำไปใช้ในโปรเจกต์ของคุณได้ทันที

curl -sS -X POST "https://api.usepolylingo.com/v1/translate" \
  -H "Authorization: Bearer $POLYLINGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "{\"nav\":{\"home\":\"Home\",\"about\":\"About us\"}}",
    "format": "json",
    "targets": ["fr", "de", "es", "ja", "nl"]
  }'

คำขอเดียว ห้าภาษา โครงสร้างครบถ้วน

เนื้อหา Markdown

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

PolyLingo มีแฟล็ก markdown ที่สั่งให้โมเดลปฏิบัติต่อไวยากรณ์ Markdown เป็นโครงสร้าง ไม่ใช่ข้อความที่แปลได้ หัวเรื่องยังคงเป็นหัวเรื่อง บล็อกโค้ดที่มีรั้วถูกเก็บไว้ตามเดิม URL ของลิงก์ไม่ถูกเปลี่ยนแปลง มีเพียงเนื้อหาข้อความที่เปลี่ยน

สำหรับเว็บไซต์เอกสารหรือบล็อกที่มีเนื้อหาทางเทคนิค ความแตกต่างนี้สำคัญมาก บล็อกโค้ดที่เสียหายในบทเรียนไม่ใช่แค่ปัญหาการนำเสนอเล็กน้อย แต่มันคือบทเรียนที่เสียหาย

ความแตกต่างระหว่างคำขอหนึ่งคำขอกับหนึ่งคำขอต่อภาษา

เรื่องนี้ควรให้ความสนใจเพราะมีผลต่อค่าใช้จ่ายจริง

DeepL API รับได้เพียงภาษาปลายทางเดียวต่อคำขอ หากจะแปลเนื้อหาเป็นสิบภาษา คุณต้องส่งคำขอสิบครั้ง สำหรับไซต์ขนาดใหญ่หรือ CMS ที่เผยแพร่บ่อย นั่นคือค่าใช้จ่ายคำขอเพิ่มสิบเท่า ความหน่วงเวลาเพิ่มสิบเท่า และจุดล้มเหลวเพิ่มสิบเท่า

PolyLingo รับอาร์เรย์ของรหัสภาษาปลายทางและส่งกลับการแปลทั้งหมดในคำตอบเดียว สามสิบหกภาษา คือคำขอหนึ่งครั้ง ไม่ใช่สามสิบหกครั้ง

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

รูปแบบการคิดราคา

DeepL คิดราคาตามจำนวนตัวอักษร แผน API ฟรีอนุญาตสูงสุด 500,000 ตัวอักษรต่อเดือน และแผนชำระเงินคิดตามการใช้ตัวอักษร เพราะคุณส่งคำขอหนึ่งครั้งต่อภาษา จำนวนตัวอักษรของเนื้อหาจะถูกคูณด้วยจำนวนภาษาปลายทางที่คุณส่งในคำขอแยกกัน

PolyLingo คิดราคาตามโทเค็นและนับรวมทั้งอินพุตและเอาต์พุตสำหรับทุกภาษาในคำขอเดียว การคิดราคาชัดเจนและคาดการณ์ได้: แผนฟรีรวม 50,000 โทเค็นต่อเดือน แผนชำระเงินเริ่มต้นที่ $9 ต่อเดือนสำหรับ 600,000 โทเค็น

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

เหมาะกับใคร

DeepL API เหมาะเมื่อ:

เนื้อหาของคุณเป็นข้อความธรรมดาไม่มีข้อกำหนดโครงสร้าง
คุณภาพการแปลสำหรับข้อความที่มนุษย์อ่านได้เป็นเรื่องสำคัญ
คุณแปลเป็นภาษาจำนวนน้อยและปริมาณคำขอน้อย
คุณลงทุนในระบบนิเวศของ DeepL และใช้พจนานุกรมหรือฟีเจอร์ความเป็นทางการของพวกเขา
คุณต้องการสนับสนุนภาษาที่ PolyLingo ยังไม่มี (DeepL รองรับมากกว่า 100 ภาษา)

PolyLingo เหมาะเมื่อ:

เนื้อหาของคุณเป็น JSON, Markdown หรือ HTML และต้องรักษาโครงสร้าง
คุณต้องแปลเป็นหลายภาษาในคำขอ API เดียว
คุณกำลังสร้างการรวม CMS หรือสายงาน i18n ที่ประสิทธิภาพคำขอสำคัญ
คุณต้องการอินเทอร์เฟซที่สอดคล้องกันสำหรับทุกรูปแบบเนื้อหาโดยไม่ต้องใช้วิธีแก้ไขเฉพาะรูปแบบ
คุณต้องการการคิดราคาตามโทเค็นที่มีการให้โควตารายเดือนที่คาดการณ์ได้

สรุปเปรียบเทียบ

	PolyLingo	DeepL API
สนับสนุน JSON โดยตรง	ใช่	ไม่
สนับสนุน Markdown โดยตรง	ใช่	ไม่
สนับสนุน HTML	ใช่	ใช่ (แฟล็ก tag_handling)
ทุกภาษาภายในคำขอเดียว	ใช่	ไม่, หนึ่งภาษาต่อคำขอ
ตรวจจับรูปแบบเนื้อหาอัตโนมัติ	ใช่	ไม่
ภาษาที่รองรับ	36	100+
แผนฟรี	50,000 โทเค็น/เดือน	500,000 ตัวอักษร/เดือน
หน่วยคิดราคา	โทเค็น	ตัวอักษร
ตัวแปลเว็บไม่ต้องเขียนโค้ด	ใช่	ใช่ (เว็บแอป)

DeepL มีแคตตาล็อกภาษาที่ใหญ่กว่าและประวัติการแปลข้อความธรรมดาที่ยาวนานกว่า PolyLingo ถูกสร้างขึ้นเพื่อสายงานเนื้อหาที่มีโครงสร้างซึ่งความสมบูรณ์ของรูปแบบเป็นสิ่งที่ไม่สามารถต่อรองได้

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

ลองใช้ PolyLingo

แผนฟรีรวม 50,000 โทเค็นต่อเดือน ไม่ต้องใช้บัตรเครดิต เอกสาร API เต็มรูปแบบอยู่ที่ usepolylingo.com/docs

curl -sS -X POST "https://api.usepolylingo.com/v1/translate" \
  -H "Authorization: Bearer $POLYLINGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "# Hello\n\nThis is **structured** content.",
    "format": "markdown",
    "targets": ["fr", "de", "es"]
  }'

รับคีย์ API ของคุณ

PolyLingo กับ DeepL API: อันไหนเก็บรักษา JSON และ Markdown ได้ดีกว่า?