การตั้งค่า custom API ของ Immersive Translate

เปิด service setting ของ OpenAI

หน้า OpenAI service อย่างเป็นทางการของ Immersive Translate อธิบาย custom API address ไว้ใต้ More Settings เริ่มจากจุดนี้เมื่อประเมิน OpenAI-compatible endpoint บันทึก extension version และ browser เพื่อให้ setup check ภายหลังอ้างถึง environment ที่ทำซ้ำได้

เลือก configuration เดียวสำหรับ test แรก และเก็บ default setting ไว้กู้คืน ป้อน credential เฉพาะใน private extension setting ยืนยันว่า endpoint เป็นผู้รับที่ตั้งใจก่อนส่ง page content โดยเฉพาะเมื่อ browser เดียวกันเข้าถึงหน้าจัดการร้านค้าได้

ตรวจว่า address เป็น base หรือ full route

อย่าสมมติว่า custom-address field ทุกตัวทำงานเหมือน SDK baseURL หน้า official มี full chat-completions URL ใน Azure example ตรวจ help text ของ extension ที่ติดตั้งและ request path ขาออกที่ sanitize แล้ว เพื่อรู้ว่า address ถูกใช้แบบใด

สำหรับ APIsRouter chat-completions candidate full route คือ https://api.apisrouter.com/v1/chat/completions หาก version ที่ติดตั้งระบุชัดว่าต้องการ base URL แล้วต่อ route เอง ให้ใช้ https://api.apisrouter.com/v1 แทน หลีกเลี่ยง suffix chat/completions ซ้ำสองครั้ง worksheet ด้านล่างอธิบาย candidate setting ไม่ใช่ extension configuration ที่ทดสอบแล้ว

Service: OpenAI
Settings area: More Settings > custom API address
Full request URL candidate: https://api.apisrouter.com/v1/chat/completions
Base-only candidate, if required by installed version: https://api.apisrouter.com/v1
Credential: gateway key entered privately
Model: exact current catalog ID with verified chat behavior

ทำให้ translation request path มองเห็นได้

extension ส่ง translation request ไปยัง service address ที่เลือก ถือ address นี้เป็นการตัดสินใจเรื่องการแชร์ข้อมูล ไม่ใช่เพียง field เชื่อมต่อ ใช้ content ที่คุณเป็นเจ้าของหรือได้รับอนุญาตให้ประมวลผลผ่าน endpoint ที่เลือก และรีวิวว่า translation action ที่เลือกส่ง page ไปมากเพียงใด

flow ด้านล่างแสดง gateway path ที่เสนอโดยใช้ custom-address mechanism ตามเอกสาร selected-model label เป็น configuration choice ไม่ใช่รายการ model ที่ยืนยันแล้ว Store authentication, product editing และ import approval อยู่นอก request path นี้

ตรวจหน้า controlled page เดียวก่อน

ใช้หน้าสั้นๆ ที่มี synthetic product description, protected brand term, quantity พร้อม unit และ link แปลเฉพาะหน้านั้น เปรียบเทียบผลลัพธ์ที่เห็นกับ source และตรวจ sanitized network destination, selected model และ response status

ตรวจว่า content หาย ซ้ำ หรือปะปนกับภาษาต้นฉบับหรือไม่ จากนั้นลองย่อหน้าที่ยาวขึ้นและ layout ที่มี heading หรือ list เก็บ source กับ output ที่สังเกตได้ไว้ เพื่อเทียบกับการเปลี่ยน configuration ภายหลัง วิธีนี้สร้าง diagnostic baseline ที่มีประโยชน์ก่อนประมวลผลเอกสารขนาดใหญ่

ใช้ bilingual reading กับคำถามเชิงบรรณาธิการ

Browser translation ช่วย reviewer ตรวจ source ที่ไม่คุ้นหรือชี้วลีที่ต้องสนใจ ให้ต้นฉบับมองเห็นและเทียบ claim, quantity และ terminology โดยตรง หาก reviewer ประเมิน target language ไม่ได้ ให้ส่งต่อคนที่ประเมินได้ แทนการถือว่าภาษาลื่นไหลเป็นหลักฐาน

เก็บ glossary decision ไว้ใน catalog workflow อย่าสมมติว่า custom endpoint มี glossary enforcement หรือ field-level validation ภายใน extension ด้วย Product description ที่จะ import ยังต้องมี candidate ที่เชื่อม source ผลรีวิว และ destination mapping ของตัวเอง

วินิจฉัย error ก่อนแปล content เพิ่ม

เริ่มจาก request path, credential และ exact model ID เก็บ structured error เมื่อมี และ redact header ก่อนแชร์ evidence หาก request ถูกจำกัด ให้ลด workload และเคารพ retry guidance ของ service แทนการทำ full-page translation ซ้ำอย่างรวดเร็ว

ใช้ passage ที่เล็กกว่าเพื่อแยก connection failure ออกจากปัญหา content หรือ response handling เปลี่ยน setting ทีละตัว หน้า official มีตัวอย่างราคาและ request-rate แบบ historical ให้ใช้เอกสารและ account limit ของ endpoint ปัจจุบัน แทนการคัดลอกตัวเลขเหล่านั้นลงในการตั้งค่าใหม่

แยก browser output ออกจาก catalog delivery

Browser view ที่แปลแล้วเป็น inspection surface หากต้องการเผยแพร่ product text ให้สร้าง candidate ใน catalog review package เก็บ identifier และ source revision แล้วส่ง field ที่อนุมัติผ่าน import หรือ translation API จริงของร้าน

ตรวจ delivery ด้วยการอ่าน field ที่จัดเก็บและเปิด storefront locale ที่ตั้งใจ อย่าพึ่ง browser extension ของ editor เพื่อพิสูจน์สิ่งที่ visitor ทั่วไปเห็น บันทึก translation request usage แยกจาก store operation และนับ retry ตอนประเมิน workload ใช้ราคาปัจจุบันแทนการสมมติต้นทุนคงที่ต่อหน้า หรือต่อตัวอักษร

หลักฐานและข้อจำกัดของ integration

เอกสารทางการยืนยัน custom-address setting แล้ว แต่ยังไม่ได้ทดสอบ installed-extension request ผ่าน APIsRouter สำหรับบทความนี้ ดังนั้น behavior ของ address ที่แน่นอน ความเข้ากันได้ของโมเดล และผลลัพธ์ที่ render ยังเป็น setup check diagram เป็น configuration flow เพื่ออธิบาย ไม่ใช่ผลทดสอบ

compatibility record ที่เสร็จควรมี extension และ browser version, sanitized setting, request destination, exact model, controlled source page และ translation ที่สังเกตได้ แยก protected-field review ออกจาก transport check นี้ passage สั้นที่สำเร็จไม่ได้ validate document format ทุกแบบหรือ store publishing workflow

คำถามที่พบบ่อย