Thai Doc

ถือว่าเป็น Proposal ฉบับ Alpha แล้วกัน

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

ลองหัดเขียนโปรแกรมด้วย VS.NET สิครับ หนังสืออาจจะหาง่ายกว่าร้านขายกล้วยแขก กลับกันลองพยายามเขียนด้วย mono กับ SharpDevelop…..

ผมเข้าสู่โลกการแปลเอกสารครั้งแรกๆ ด้วยการแปลวิธีการใช้งานโปรแกรม SuperVersion ซึ่งหายไประหว่างการย้าย Blognone อย่างน่าเสีัยดาย ตอนนั้นเกิดอาการบ้าบิ่นเมลไปขอแปลเค้าดื้อๆ ผลที่เกิดขึ้นคือ tutorial ฉบับนั้นมีภาษาที่สองเป็นไทย!!! เจ้าของโปรแกรมดีใจโพสลง mailing-list เป็นเรื่องเป็นราว เข้าไปอ่านช่วงหลังมีชาติอื่นยอมไม่ได้ไล่แปลแข่งกับผมอีกสองสามภาษา

ความรู้ฟรีๆ ในโลกนี้มีมหาศาล น่าเศร้าที่คนของเราเข้าถึงมันไม่ได้

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

กระบวนการทำงานที่คิดไว้คร่าวๆ คือ

  • มีตัวแทนไปขออนุญาตมาก่อนให้เรียบร้อย หรือถ้าไม่ต้องขอก็ควรแจ้งเจ้าของเอกสารให้เรียบร้อย อย่างน้อยเขาจะได้ไม่ให้ใครมาทำงานซ้ำกับเรา
  • ต่อมาเอาเอกสารต้นฉบับมาแปลงให้อยู่ในรูปไฟล์ TMX หรือ XLIFF เพื่อเตรียมการแปล
  • ตกลงกันให้เรียบร้อย ว่าใครจะแปลท่อนไหน
  • Build เอกสารกลับออกมาเผยแพร่ทุกสัปดาห์
  • วนแก้ไข ในส่้วนของความถูกต้องไปเรื่อยๆ

ทรัพยากรที่ยังขาดอยู่

  1. คน ชวนเอาแถวๆ นี้จะมีใครเล่นด้วยป่าวหว่า ไปกวาดคนจาก Blognone น่าจะช่วยได้
  2. CVS/Subversion ถ้าให้ดีต้องมี Trac ด้วย เมืองไทยจะมีแบบ SourceForge มั๊ยเนี่ย

แค่นี้เองนี่หว่า

แต่ก่อนอื่นเลยต้องเอาโปรแกรมแปลมาลองซะก่อน….

ขั้นตอนและแนวคิดยังมั่วๆ อยู่ แต่บอกไว้แล้วว่านี่คือ Alpha

 

Translation Memory

ยังว่าด้วยเรื่องของการแปลกันต่อ

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

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

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

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

ข้อดีอีกอย่างคือไฟล์ Translation Memory เช่น TMX มักจะง่ายต่อการ Merge มากๆ ทำให้ใช้โปรแกรมพื้นฐานเช่น Winmerge มารวมเอกสารเอาได้สบายๆ

ปล. Winmerge ไม่รองรับ UTF-8 แฮะ

 

ว่าด้วยการแปล

รวบรวมเอาความคิดที่กระจัดกระจายมาเป็นหมวดหมู่ซักที

เรื่องแรกเลยคือมาตรฐานไฟล์ในการแปล เท่าที่รู้มีอยู่สามสี่อันที่นิยมใช้กัน

  1. ไฟล์ PO ที่ใช้กันในโครงการใหญ่ๆ อย่าง OpenOffice แต่มักใช้ในโครงการเขียนโปรแกรมมากกว่าที่จะใช้ในการแปลเอกสารอย่างจริงจัง
  2. TMX เป็นไฟล์ที่ใช้ตอนที่แปลบทพูดของ RMS แล้วได้รับรู้ว่าโลกนี้มีอะไรที่ดีกว่าการเปิดเว็บหน้านึง เวิร์ดโปรเซสเซอร์อีกหน้านึงแล้วลงมือแปล
  3. XLIFF คงเ็ป็นตัวที่ดีที่สุดเท่าที่นึกออก เพราะเป็นมาตรฐานของทาง OASIS-OPEN ทำให้น่าสนใจขึ้นเยอะ ที่สำคัญคือมีโปรแกรมรองรับเยอะมาก

เรื่องต่อมาโปรแกรมที่ใช้ในการแปล ตรงนี้คงต้องเลือกเอาสักอัน เพื่อเขียนคำแนะนำขั้นตอนในการแปลให้คนที่ต้องการเข้าร่วมทำได้โดยง่าย ข้อกำหนดคือมันต้อง Portable เพราะต้องให้คนเข้าถึงได้จากทุก OS ตัวเลือกหลักๆ เลยอาจจะต้องเป็น Java หรือ .NET ตัวเลือกที่มองๆ ไว้ตอนนี้ก็มี

  1. OmegaT เป็นตัวแรกที่รู้จัก และเป็นตัวเดียวที่ผมใช้เป็น ใช้ง่ายและเวิร์คจริง แต่ยังไม่แน่ใจว่าดีที่สุด
  2. Transolution ตัวนี้เป็น Python น่าจะเร็วกว่า แต่คนพัฒนาหยุดการพัฒนาไปแล้วเมื่อต้นปี ยังไม่มีทีท่าว่าจะมีใครมารับต่อ เลยไม่น่าเลือก
  3. Open Language Tools เป็นตัวที่ SUN พัฒนาขึ้นมาแจก เท่าที่อ่านสเปคแล้วดูดีสุดแล้ว แต่ดูเหมือนว่าการพัฒนาจะนิ่งไปแล้วเหมือนกัน
  4. Rainbow 4 ตัวนี้เป็น .NET อ่านหน้าเว็บแล้วยังแปลกๆ ว่ามันใช่โปรแกรมแปลแน่รึเปล่า
  5. XLIFF Tools ใช้แปลง XLIFF กับ PO น่าจะมีประโยชน์ในอนาคต
  6. Pootle ข้อดีของตัวนี้คือเป็น Web-Based แต่ดันรับแต่ไฟล์ PO ทำให้อาจจะต้องใช้ร่วมกับตัวข้างบน

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

เมื่อยล่ะ ไว้มาคิดต่อ…