Skills for Translation

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

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

ในแง่เทคโนโลยีที่ใช้ งานแปลไม่ต้องการเครื่องมือที่ซับซ้อนอะไรมาก แค่ PO editor สักตัวก็พอแล้ว หรืออย่างหรูหน่อยก็เป็น web-based อย่าง pootle หรือ launchpad (ที่ผมไม่ชอบ เพราะเชื่องช้าเกินไป สู้การทำงานออฟไลน์ไม่ได้) หรือเครื่องมือจัดการ translation memory และ glossary แต่เขาไม่ต้องรู้เทคโนโลยีอะไรที่มากกว่านั้นอย่างที่การเขียนโปรแกรมต้องการ นั่นคือสิ่งที่คนทั่วไปประเมินงานแปล แต่มักจะไม่ได้คำนึงถึงทักษะอื่น ๆ ของผู้แปล เพื่อให้ได้งานแปลที่ดีด้วย

พูดสั้น ๆ คือ แปลน่ะง่าย แต่แปลให้ดีนั้น ต้องมีกึ๋นพอสมควร

บอกไว้ก่อนว่าเจตนาของการเขียน blog นี้ คือการอธิบายถึงทักษะที่จำเป็นสำหรับงานแปล โดยหวังให้งานแปลได้รับการยอมรับหรือใส่ใจมากขึ้น ไม่ได้เขียนเพื่อทำให้ผู้ที่อยากร่วมแปลกลัวจนไม่กล้าเข้าร่วม ทักษะนั้นฝึกกันได้ครับ อย่างที่ Brian Kernighan บอก ว่า "วิธีที่ดีที่สุดในการเรียนเขียนโปรแกรม ก็คือการลงมือเขียน" งานแปลก็ไม่ต่างกันครับ

ขอแยกทักษะที่จำเป็นเป็นสองเรื่อง คือสำหรับนักแปลโดยทั่วไป และสำหรับผู้ประสานงานแปลที่ต้องทำงานกับ source tree โดยตรง

สำหรับนักแปลทั่วไป

การแปลซอฟต์แวร์ ก็คล้ายกับการแปลทั่วไป ตรงที่ต้องมีความเข้าใจในสิ่งที่แปลพอสมควร ดังนั้น ทักษะที่จำเป็นก็คงเป็น:

• ภาษาอังกฤษ ต้องอ่านภาษาอังกฤษเข้าใจ รู้จักรูปประโยคหรือสำนวนต่าง ๆ และสามารถจับใจความของทั้งประโยคได้อย่างถูกต้อง อย่างน้อย ๆ ต้องไม่ใช่การแปลแบบคำต่อคำ แต่ต้องเข้าใจทั้งประโยคก่อนแปล
• ภาษาไทย อันนี้สำคัญไม่แพ้กัน เมื่อเข้าใจประโยคภาษาอังกฤษแล้ว ก็ต้องสามารถเลือกคำภาษาไทยที่อธิบายความหมายได้อย่างเหมาะเจาะ พร้อมทั้งเรียบเรียงได้อย่างสละสลวย ผมพบว่า ทักษะนี้บางครั้งต้องใช้ความคิดสร้างสรรค์อย่างมาก ซึ่งการระดมความคิดในชุมชนสามารถช่วยได้ นอกจากนี้ เพื่อคุณภาพงานแปลที่ดี การสะกดคำก็ต้องแม่น รู้ศัพท์บัญญัติอย่างเพียงพอ หรือสามารถสืบค้นได้
• เข้าใจเทคโนโลยี เป็นทักษะที่ทำให้นักแปลนิยายกับนักแปลซอฟต์แวร์ต่างกัน นักแปลซอฟต์แวร์อาจไม่ต้องรุ่มรวยสำนวนอะไรมาก แต่จะแปลอะไรก็ต้องเข้าใจในสิ่งนั้น ต้องเข้าใจความหมายที่แตกต่างจากคำสามัญของศัพท์เทคนิคต่าง ๆ เพื่อที่จะตีความได้ไม่ผิดเพี้ยน
• เข้าใจการทำงานของโปรแกรม ข้อความจำนวนมากเป็นข้อความสั้น ๆ แต่ตีความได้หลายแบบ การที่จะเลือกความหมายที่เหมาะสม ก็ต้องเข้าใจการทำงานของโปรแกรมด้วย ว่าข้อความไปปรากฏที่ไหน เวลาใด โปรแกรมมีเงื่อนไขการทำงานอย่างไร ความเข้าใจอย่างถ่องแท้จะทำให้ได้คำแปลที่ไม่ทำให้ผู้ใช้งง ตัวอย่างที่ผมยกบ่อย ๆ คือ "Receiving mails" จะแปลว่า "การรับเมล" หรือ "กำลังรับเมล" ก็ต้องพิสูจน์ทราบให้ได้ ถ้าสามารถแกะซอร์สโค้ดได้ก็จะยิ่งชัดเจน แต่ถ้าไม่ได้ ก็อาจต้องใช้วิธีทดลองเอา
• ความรู้รอบตัว เนื่องจากงานแปลมักมีขอบเขตครอบคลุมหลายโปรแกรม บางครั้งก็จำเป็นต้องอาศัยความรู้รอบตัวเกี่ยวกับสาขาต่าง ๆ เช่น เรื่องชื่อประเทศ ชื่อเมือง วัฒนธรรมต่าง ๆ ในโลกที่อาจเป็นต้นตอของการยืมชื่อมาใช้ในโปรแกรม คำศัพท์ที่ใช้กันในวงการที่เกี่ยวข้อง เช่น แปลโปรแกรมกราฟิกส์ก็ต้องเข้าใจศัพท์ของศิลปะและสิ่งพิมพ์ แปลโปรแกรมสื่อประสมก็ต้องเข้าใจศัพท์กล้อง ศัพท์การทำสื่อ ฯลฯ
• เข้าใจเรื่องทางเทคนิคที่จำเป็น เช่น เข้าใจ format string ของภาษา C, C#, Python เพียงพอ เข้าใจ format string ของ strftime การกำหนดปุ่มลัดของเมนู และเรื่องที่เกี่ยวกับการแปลโดยตรง เช่น plural form, การใช้เครื่องมือ gettext เบื้องต้น

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

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

สำหรับผู้ประสานงานแปล

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

ดังนั้น ทักษะเพิ่มเติมที่ควรมีนอกเหนือจากการแปลตามปกติคือ:

• การใช้ version control หรือระบบติดตามบั๊ก เพื่อจะได้ทำงานกับ source tree ได้ การใช้งานนี้ รวมถึง การ checkout, update, commit ธรรมดา และการ diff เพื่อมองหาการเปลี่ยนแปลงของข้อความในโปรแกรม หรือข้อความที่มีคำแปลใหม่เข้ามา
• การใช้เครื่องมือของ gettext หรือ intltool เพื่อจัดการกับแฟ้ม PO และสร้าง diff ที่เล็กที่สุดเพื่อความสะดวกในการตรวจทานการเปลี่ยนแปลงต่าง ๆ เครื่องมือที่ผมเองใช้บ่อย (คนอื่นอาจใช้มากกว่านี้) คือ:
  • intltool-prepare - สร้าง POT โดยดึงข้อความจากโปรแกรม เพื่อเริ่มแปลโปรแกรมที่ไม่เคยแปลมาก่อน (DL ของ GNOME ทำให้ได้)
  • intltool-update - ดึงข้อความจากโปรแกรมมาใหม่ และ merge เข้ากับ PO ที่มีอยู่เพื่อเริ่มแปลต่อ (DL ของ GNOME ทำให้ได้)
  • msgfmt - แปลง PO เป็น MO เพื่อตรวจสอบความถูกต้อง และดูอัตราการแปล
  • msgcat - จัดข้อมูล PO ให้อยู่ในรูปปกติ เช่น แบ่งบรรทัดละไม่เกิน 80 คอลัมน์, จัดบรรทัด comment เป็นต้น การจัดรูปแบบก่อน diff จะทำให้ได้ diff ที่เล็กที่สุด
  • msgmerge - merge คำแปลจาก PO ใหม่เข้าใน PO เก่า เพื่อปรับข้อมูลคำแปลก่อน diff

เครื่องมือเหล่านี้ จะช่วยให้ผู้ประสานงานรับมือกับ PO ที่มาจากนักแปลได้ทุกรูปแบบ ไม่ว่าจะแปลมาจาก poedit, pootle, launchpad หรืออะไรก็แล้วแต่ โดยสามารถตรวจหาเฉพาะส่วนที่มีการเปลี่ยนแปลงเพื่อตรวจทานได้

บางคนอาจจะบอกว่า เครื่องมืออย่าง pootle, transifex หรือ launchpad มีการรองรับเรื่องพวกนี้อยู่แล้ว ก็ไม่มีปัญหาครับ แต่ถ้าจะทำงานกับ VCS โดยตรง เครื่องมือพวกนี้ก็จำเป็น

รายละเอียดปลีกย่อยอื่น ๆ ก็เป็นเรื่องของสไตล์ของแต่ละคนนะครับ บางคนอาจจะไม่นิยมทำงานแปลก่อน string freeze แต่สำหรับผม เป็นประเภทชอบทยอยผ่อนส่ง บางทีก็จะเริ่มแปลตั้งแต่ยังเป็น development snapshot อยู่ โดยปกติสำหรับ GNOME ก็จะเริ่ม switch jhbuild ให้ไปเป็น development branch หลังจากที่ออก stable *.1 release แล้ว แล้วก็ตาม update คำแปลไปเรื่อย ๆ ซึ่งจะทำให้ปริมาณงานในแต่ละครั้งไม่มากนัก ช่วยลดปริมาณงานในขั้น string freeze ได้พอสมควรทีเดียว

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