สร้างคอนเทนต์เทคนิคให้เข้าถึงคนต่างวัฒนธรรม: เกณฑ์เลือกเครื่องมือ ทีมงาน และงบประมาณ

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

สรุปแบบเร็ว

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

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

คำตอบสั้น: คอนเทนต์เทคนิคที่เข้าถึงต่างวัฒนธรรมต้องออกแบบมากกว่าภาษา

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

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

สรุป 3 จุดที่ต้องตรวจตั้งแต่ก่อนเริ่มเขียน

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

แยกความต่างระหว่างการแปล การปรับให้เข้าท้องถิ่น และการออกแบบเพื่อการเข้าถึง

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

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

เปรียบเทียบทำเอง ใช้ AI จ้างนักแปล หรือใช้บริการ localization แบบองค์กร

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

ตารางเทียบเวลา งบประมาณ ความเสี่ยง และความเหมาะสมของแต่ละทางเลือก

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

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

งานประเภทใดที่ไม่ควรพึ่งการแปลอัตโนมัติเพียงอย่างเดียว

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

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

ขั้นตอนวางแผนเนื้อหาเทคนิคสำหรับผู้ใช้หลายวัฒนธรรม

การวางแผนก่อนเขียนช่วยลดการแก้ไขหลังแปล โดยเฉพาะเมื่อเนื้อหาต้องเผยแพร่หลายภาษา หรือมีการอัปเดตคู่มือบ่อยครั้ง

กำหนดกลุ่มผู้ใช้ สถานการณ์ใช้งาน และศัพท์เทคนิคหลัก

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

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

เขียนต้นฉบับให้แปลและอ่านต่อได้ง่าย

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

โครงสร้างหัวข้อควรสะท้อนลำดับการทำงาน เช่น “ก่อนเริ่มต้น” “ขั้นตอนการตั้งค่า” และ “วิธีตรวจสอบผลลัพธ์” วิธีนี้ช่วยทั้งผู้อ่านและทีมที่ดูแลการแปลหรือระบบจัดการเนื้อหาองค์กร

ปรับวันที่ เวลา หน่วยวัด สกุลเงิน ภาพ และตัวอย่างให้เข้าบริบท

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

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

จุดเสี่ยงที่ทำให้คู่มือใช้งานสื่อสารผิด แม้ภาษาไวยากรณ์ถูกต้อง

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

ชื่อเมนู ปุ่ม และคำสั่งไม่ตรงกับผลิตภัณฑ์จริง

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

ใช้สำนวน อารมณ์ขัน หรือภาพที่ตีความต่างกัน

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

ละเลยข้อความทางเลือกของภาพ โครงสร้างหัวข้อ และความชัดเจนของคำสั่ง

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

ปรับวิธีทำตามประเภทงานและระดับผลกระทบ

การแบ่งประเภทงานช่วยให้ทีมไม่ต้องใช้กระบวนการหนักเท่ากันกับทุกหน้า แต่ยังรักษาจุดที่ควรตรวจอย่างเหมาะสม

บทความช่วยเหลือและ FAQ สำหรับผู้ใช้ทั่วไป

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

เอกสาร SaaS คู่มือระบบ และหน้า onboarding สำหรับลูกค้าองค์กร

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

เนื้อหาที่เกี่ยวกับราคา สัญญา ความปลอดภัย หรือข้อมูลสำคัญต่อการตัดสินใจ

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

เกณฑ์เลือกเครื่องมือและผู้ให้บริการก่อนลงทุน

ก่อนเปรียบเทียบแพลตฟอร์ม localization บริการแปล หรือเอเจนซี ควรกำหนดสิ่งที่ทีมต้องการควบคุมให้ชัด เช่น คำศัพท์ เวอร์ชันงาน ผู้อนุมัติ และความถี่ในการอัปเดต

ตรวจความสามารถด้านคำศัพท์เฉพาะ เวิร์กโฟลว์อนุมัติ และการควบคุมเวอร์ชัน

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

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

คำถามสำหรับขอใบเสนอราคาและกำหนดขอบเขตงาน

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

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

สรุปการเลือกตามปริมาณเนื้อหา ความถี่การอัปเดต และความเสี่ยงต่อแบรนด์

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

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

เกณฑ์เลือกและสรุปเปรียบเทียบ

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

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

สรุปส่งท้าย

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

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

ข้อมูลที่ควรรู้เพิ่มเติม

1. ควรเก็บรายการคำศัพท์เทคนิคที่ใช้ร่วมกันระหว่างผู้เขียน ผู้แปล และผู้ตรวจทาน

2. ตรวจภาพ สี สัญลักษณ์ และตัวอย่างแยกจากการตรวจข้อความ

3. ใช้การทดสอบกับผู้ใช้หรือผู้ตรวจที่เข้าใจตลาดเป้าหมายเพื่อค้นหาจุดกำกวมก่อนเผยแพร่

4. เมื่อผลิตภัณฑ์เปลี่ยน ควรตรวจว่าคู่มือหลายภาษายังอ้างอิงชื่อเมนูและขั้นตอนเดียวกับหน้าจอจริง

ข้อควรระวังสำคัญ

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

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

Q1. คอนเทนต์เทคนิคจำเป็นต้องจ้างนักแปลเฉพาะทางทุกครั้งหรือไม่?

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

Q2. ใช้ AI แปลคู่มือซอฟต์แวร์ได้ปลอดภัยแค่ไหน และควรตรวจอะไรเพิ่ม?

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

Q3. ควรตั้งงบสำหรับบริการ localization อย่างไรเมื่อยังไม่ทราบปริมาณงานแน่นอน?

A3. เริ่มจากจัดกลุ่มเนื้อหาตามความเสี่ยงและความถี่ในการอัปเดต แล้วเตรียมข้อมูลคู่ภาษา ประเภทเนื้อหา ปริมาณโดยประมาณ และระดับการตรวจที่ต้องการเพื่อขอขอบเขตงานและใบเสนอราคา งบจริงอาจแตกต่างตามความยาว ความซับซ้อน คู่ภาษา และขอบเขตการตรวจทาน