ขณะนี้ฉันกำลังพัฒนาเว็บแอปพลิเคชันใหม่โดยใช้ไคลเอนต์ JavaScript ที่มีการสื่อสารกับบริการเว็บ REST หลายแห่งบนเซิร์ฟเวอร์ของฉัน แอปพลิเคชันนั้นมีวัตถุประสงค์เพื่อใช้ในประเทศอย่างน้อยสองที่มีภาษาแตกต่างกันดังนั้นเราจึงจำเป็นต้องแปลเป็นภาษาท้องถิ่น
คำถามของฉันคือที่ใดที่ฉันควรจัดการการแปล: บริการ REST ควรได้รับการร้องขอและส่งคำตอบกับข้อมูลที่แปลแล้วหรือลูกค้าควรรับและส่งข้อมูลทั่วไปแล้วรับผิดชอบในการแปล
คำตอบ:
REST API ของคุณจะง่ายต่อการใช้งานโดยผู้อื่นหากคุณระบุ ID สตริงแทนการแปลสตริง การใช้ API ซึ่งผลตอบแทน"E_NOT_AUTHORIZED"จะตรงไปตรงมามากกว่าถ้ามันคืนค่าภาษามนุษย์บางส่วนและแม้แต่สตริงที่แปลเป็นภาษาท้องถิ่น
นอกจากนี้คุณอาจต้องการเปลี่ยนสตริงที่แปลเป็นภาษาท้องถิ่นในเวอร์ชันอนาคตซึ่งจะเป็นการเปลี่ยนแปลง API ที่ไม่สมบูรณ์ ด้วยวิธีการที่ ID สตริงคุณยังคงกลับมา"E_NOT_AUTHORIZED"ทำให้ API ของคุณเข้ากันได้
หากคุณใช้เฟรมเวิร์กอย่างAngular.jsการปรับใช้ hot-switching ภาษานั้นง่ายหากคุณใช้วิธีการ ID สตริง คุณเพียงแค่โหลด STRINGTABLE {{errorStringID | loc}}อื่นและสตริงทั้งหมดโดยอัตโนมัติเปลี่ยนภาษาของพวกเขาเพราะคุณเพียงแค่ใช้ตรรกะกรองบางอย่างในแม่แบบของคุณเช่น
ข้อควรพิจารณาอื่น: เพื่อลดโหลดเซิร์ฟเวอร์ให้แบ็คเอนด์ของคุณง่ายที่สุดเท่าที่จะทำได้ คุณจะสามารถให้บริการลูกค้าได้มากขึ้นด้วยจำนวนเซิร์ฟเวอร์เท่ากัน ส่ง stringtables ของคุณผ่าน CDN และทำการแปลในส่วนหน้า
ให้ไคลเอนต์ส่งAccept-Languageส่วนหัวมาตรฐานในการร้องขอจากนั้น จำกัด วงบนเซิร์ฟเวอร์และรวมContent-Languageส่วนหัวในการตอบกลับ ดูRFC 7231 ส่วน 5.3.5สำหรับรายละเอียด
การโลคัลไลซ์บนฝั่งเซิร์ฟเวอร์ส่งผลให้มีการเดินทางไปกลับน้อยลงและปริมาณการใช้แบนด์วิดท์น้อยกว่าการส่งเมตาดาต้าการแปลเป็นภาษาท้องถิ่น แต่เซิร์ฟเวอร์ไม่สามารถสันนิษฐานได้ว่าลูกค้าต้องการภาษาอะไรเพราะหากลูกค้านั้นเป็นพร็อกซีที่ให้บริการกับคนอื่น เกิดอะไรขึ้นถ้ามีเลเยอร์แคชระหว่างไคลเอนต์และเซิร์ฟเวอร์ เซิร์ฟเวอร์ควรจะ "เพิ่งรู้ว่า" ควรใช้ภาษาใดในการร้องขอโดยพลการ
การพยายามตอบคำถามเหล่านั้นซับซ้อนดังนั้นแทนที่จะขอให้อธิบายด้วยตนเองและใช้ส่วนหัวมาตรฐานเพื่อให้ลูกค้าสามารถเจรจาภาษาที่พวกเขาต้องการ เรียกว่าการเจรจาต่อรองเนื้อหา Accept-Languageส่วนหัวเป็นรูปแบบของการเชิงรุกเจรจาเนื้อหาที่ลูกค้าบอกเซิร์ฟเวอร์สิ่งที่การตั้งค่าของมันเป็นแล้วเซิร์ฟเวอร์ตัดสินใจว่าจะตอบสนองกับตามความต้องการของผู้ที่ การเจรจาต่อรองเนื้อหาเชิงรับคือที่ลูกค้าส่งการร้องขอไปยังเซิร์ฟเวอร์ว่ามีเนื้อหาประเภทใดโดยทั่วไปจะได้รับการตอบกลับที่มีรายการลิงก์จากนั้นเลือกรายการที่ต้องการโดยเลือกลิงค์ที่จะติดตาม
ฉันจะบอกให้มากที่สุดเท่าที่เป็นไปได้ในฝั่งเซิร์ฟเวอร์ถ้าคุณจะสนับสนุนอุปกรณ์หลายเครื่อง
อุปกรณ์แต่ละตัวจะใช้การแปลบางอย่างด้วยตัวเอง แต่สิ่งที่ใช้ร่วมกันเป็นข้อความผิดพลาดจาก API ฯลฯ จะเหมือนกันโดยไม่คำนึงถึงอุปกรณ์
มันเป็นคำถามของรสนิยมส่วนตัว แต่ถ้าคุณทำสิ่งที่ฝั่งไคลเอ็นต์คุณจะประหยัดในการโหลดเซิร์ฟเวอร์ (สมมติว่าพจนานุกรมแบบคงที่หรือแคชไว้) และสามารถใช้เครื่องมือที่ไม่เชื่อเรื่องภาษาสำหรับการทดสอบบริการ