Small Font due to Synthesizing Bug

มีปัญหาหนึ่งที่เจอมาได้พักใหญ่แล้ว คิดว่าหลายคนก็คงเคยเจอ คือปัญหาบางเว็บแสดงตัวอักษรขนาดเล็ก ตัวอย่างหนึ่งที่ผมจำเอาไว้ทดสอบคือ settrade.com อันนี้มีสาเหตุมากจาก CSS ของเว็บเองที่กำหนดฟอนต์ของ <a> เอาไว้ประมาณนี้ (ตัดมาเฉพาะส่วนที่เกี่ยวข้อง):

font-family: MS Sans Serif, Tahoma, AngsanaUPC, CordiaUPC;
font-size: 8pt;

โปรดสังเกตที่ขนาดของฟอนต์.. ขนาด 8pt สำหรับ MS Sans Serif และ Tahoma อาจเป็นขนาดที่พออ่านได้ แต่ขนาด 8pt สำหรับ AngsanaUPC และ CordiaUPC แล้ว หมดสิทธิ์อ่านเลยครับ แล้วก็โชคไม่ดีเสียด้วยที่เราไม่ได้สังเคราะห์ฟอนต์ที่มาก่อน AngsanaUPC เลย AngsanaUPC ก็เลยกลายเป็นฟอนต์ที่ถูกเลือก

เรื่องนี้อาจจะโทษคนทำเว็บก็ได้ ที่ให้ตัวเลือกที่ไม่ดีมา เรื่องนี้ แม้แต่วินโดวส์ที่ถอดเอา MS Sans Serif, Tahoma ออก ก็จะเจอปัญหาเหมือนเราเหมือนกัน แต่เราก็ควรจะแก้ปัญหานี้ได้ ด้วยการทำ alias สำหรับฟอนต์พื้นฐานที่ใช้กันเยอะอย่าง MS Sans Serif และ Tahoma ด้วย เช่น เพิ่มกฎอย่างนี้เข้าไป:

<match target="pattern">
  <test qual="any" name="family">
    <string>Tahoma</string>
  </test>
  <edit name="family" mode="append" binding="same">
    <string>Waree</string>
  </edit>
</match>

(สังเกตว่าใช้ <alias> ประกอบกับ <accept> จะให้ผลที่ต่างออกไป เพราะรายการที่ accept นั้น จะถูกเพิ่มต่อท้ายแพตเทิร์น คือเสมือนกับใช้ mode="append_last" ซึ่งจะทำให้ชื่อ Waree มาทีหลัง CordiaUPC เสียอีก ถ้าทำแบบนั้น เราก็จะยังได้ AngsanaUPC อยู่ดี)

แต่ปรากฏว่า หลังจากเพิ่มกฎนี้แล้ว ก็ยังเหลือเซอร์ไพรส์อีก เพราะผลที่ได้ กลายเป็นฟอนต์ Waree ที่ถูกย่อส่วนลง!

ใน thaifonts-scalable มีการสังเคราะห์ฟอนต์ของวินโดวส์บางตัว (ตามบันทึกใน blog เก่า) คือ Angsana, Browallia และ Cordia โดยใช้ฟอนต์แห่งชาติสองตัว คือกินรีกับครุฑ สังเคราะห์สองตัวแรก และใช้ Umpush ของคุณ wd สังเคราะห์ Cordia โดยมีการย่อขนาดลงให้เท่ากับฟอนต์ในวินโดวส์ด้วย

ทีนี้ ปัญหาก็คือ กฎที่เขียนไว้นั้น รองรับแค่กรณีที่ CSS ระบุฟอนต์สังเคราะห์เพียงฟอนต์เดียว โดยแนวคิดของกฎก็คือ ตรวจสอบ match pattern ว่ามีชื่อฟอนต์ที่จะสังเคราะห์หรือเปล่า ถ้ามี ก็แก้ family ให้เป็นฟอนต์ที่มีในลินุกซ์เสีย พร้อมกับกำหนดเมทริกซ์สำหรับย่อขนาดกำกับไว้ด้วย เช่น สำหรับ Angsana ก็เป็นแบบนี้:

<match target="pattern">
  <test qual="any" name="family" mode="eq">
    <string>AngsanaUPC</string>
    <string>Angsana New</string>
  </test>
  <edit name="family" mode="assign" binding="same">
    <string>Kinnari</string>
  </edit>
  <edit name="matrix" mode="assign">
    <times>
      <name>matrix</name>
      <matrix><double>0.67</double><double>0</double>
        <double>0</double><double>0.67</double>
      </matrix>
    </times>
  </edit>
</match>

เมื่อเจอแพตเทิร์นข้างต้นที่มีหลายฟอนต์ โดยมี AngsanaUPC อยู่ในนั้น กฎนี้ก็จะถูกกระทำทันที (เพราะในส่วน <test> นั้น เราเช็กแบบ "any") โดยจะเขียนค่า "Kinnari" ลงไปแทน "AngsanaUPC" ที่ match เจอ แถมด้วยเมทริกซ์สำหรับย่อขนาด!

ทีนี้ ถ้าแพตเทิร์นนี้มีแค่ "AngsanaUPC" อย่างเดียวก็ไม่มีปัญหา เพราะพอเราแก้แพตเทิร์นไปแล้ว มันก็จะไป match เจอ Kinnari แล้วก็มาโดนเมทริกซ์ย่อขนาดลง อันนี้เป็นกรณีที่ผมทดสอบในตอนที่เพิ่มกฎ แต่พอมาเจอกรณีที่แพตเทิร์นมีหลายฟอนต์ ฟอนต์ที่ match เจอ ก็อาจจะได้ฟอนต์อื่นก็ได้ อย่างในกรณีนี้คือ Waree แล้วเราดันเขียนเมทริกซ์ลงในแพตเทิร์นเอาไว้แล้ว Waree ที่ได้ก็เลยโดนย่อส่วนลงด้วยประการฉะนี้

หลังจากนั่งนึก เดินนึกไปมา กฎนี้ไม่สามารถแก้แค่ให้ match แบบ "all" แทน "any" ได้ เพราะกฎจะไม่ทำงานเลยในกรณีที่แพตเทิร์นมีหลายฟอนต์ หลังจากลองหลาย ๆ แบบอยู่พักหนึ่ง ก็ได้คำตอบ

วิธีที่ได้ คือแยกกฎออกเป็นสองส่วน ส่วนแรกทำกับ pattern กับส่วนที่สอง ทำกับฟอนต์ที่ match เจอ

ส่วนที่ทำกับ pattern นั้น ก็แค่เติมชื่อ Kinnari ต่อท้าย Angsana เข้าไป ผมเปลี่ยนจากการเขียนทับ เพื่อให้ผู้ใช้ที่ติดตั้ง Angsana ไว้สามารถใช้ Angsana ได้ และผมไม่ใช้ <alias> ด้วยเหตุผลที่กล่าวไปข้างต้นเกี่ยวกับ Tahoma คือเราต้องการให้ Kinnari ไปแทนที่ Angsana ที่ขาดหายในลำดับที่มีการอ้างถึงเลย

กฎที่ได้ ก็มีรูปแบบเหมือนกับกฎของ Tahoma ข้างต้น:

<match target="pattern">
  <test qual="any" name="family">
    <string>AngsanaUPC</string>
    <string>Angsana New</string>
  </test>
  <edit name="family" mode="append" binding="same">
    <string>Kinnari</string>
  </edit>
</match>

จากนั้น ก็เป็นกฎสำหรับเพิ่มเมทริกซ์ย่อขนาด โดยเขียนกฎที่ target ไปที่ฟอนต์ที่ match เจอ โดยถ้าฟอนต์นั้นเป็น Kinnari ที่ match มาจากแพตเทิร์นที่อ้างถึง Angsana จึงจะกำหนดเมทริกซ์ให้:

<match target="font">
  <test name="family" mode="eq">
    <string>Kinnari</string>
  </test>
  <test target="pattern" qual="any" name="family" mode="eq">
    <string>AngsanaUPC</string>
    <string>Angsana New</string>
  </test>
  <edit name="matrix" mode="assign">
    <times>
      <name>matrix</name>
      <matrix><double>0.67</double><double>0</double>
        <double>0</double><double>0.67</double>
      </matrix>
    </times>
  </edit>
</match>

เพราะฉะนั้น ถ้าโปรแกรมระบุ Kinnari ก็จะได้ Kinnari ขนาดเต็ม แต่ถ้าระบุ Angsana ก็จะได้ Kinnari ที่มีเมทริกซ์ย่อขนาด และการใส่เมทริกซ์นี้ ทำกับฟอนต์ Kinnari ตัวเดียว ไม่ได้ไปกระทบฟอนต์อื่นใน pattern เหมือนกฎเก่า

ทดสอบดูแล้ว สามารถเปิดเว็บที่มีปัญหาข้างต้นได้ โดยได้ฟอนต์ Waree แทนที่ Tahoma โดยไม่มีการย่อส่วน และได้ commit กฎชุดใหม่นี้เข้าใน SVN แล้ว

แต่ข้อจำกัดของกฎนี้คือ ถ้าในกรณีที่ pattern มีทั้ง Angsana และ Kinnari จะถือว่าโปรแกรมต้องการ Angsana เสมอ ผมยังหาวิธีตรวจสอบลำดับก่อนหลังใน pattern ไม่เจอ ถ้าใครมีข้อแนะนำก็แนะนำได้ครับ รวมทั้งอาจจะรายงานกรณีอื่นเข้ามาด้วย เพื่อจะได้ทดสอบและแก้ไขต่อไป

Thai X locale, Extended Grapheme Cluster in Pango

หลังจากที่ GNOME 2.26 ออกไปแล้ว ก่อนที่จะเริ่มเคลียร์ TODO list ก็แปล Rhythmbox ที่มีการ แจ้งการออกรุ่นล่วงหน้า ให้กับนักแปลไว้เสียก่อน ดูเหมือนจะทันนาทีสุดท้ายก่อน 0.12.0 จะออกพอดี (วันพฤหัสที่ผ่านมา)

จากนั้น ก็มีอีกรายการหนึ่งที่ผมลืมใส่ไว้ใน TODO list คือการ update libx11 deb ซึ่งมีการปรับรุ่นเป็น 1.2 ใน sid โดยเพิ่มแพตช์ภาษาไทยเข้าไปใหม่ (ตามรายการสรุปใน blog เก่า) แต่พร้อมกันนั้น ก็ไปพบเพิ่มเติม ว่า X locale ไทยมีแฟ้ม Compose เปล่า ๆ โผล่มาด้วย ไม่แน่ใจว่ามีมาตั้งแต่รุ่นไหน แต่ผลของมันก็คือ การกำหนดโลแคล LC_CTYPE ให้เป็นไทยจะไม่เพียงพออีกต่อไปที่จะเปิดใช้ XIM ไทย แต่จะต้องกำหนด locale modifier ใน XMODIFIERS แบบเฉพาะเจาะจงด้วย (ดูรายละเอียดการกำหนด XMODIFIERS ใน บทความใน homepage) มิฉะนั้น แฟ้ม Compose จะทำให้ XIM ของยุโรปที่ชื่อ "local" ถูกเรียกขึ้นมาใช้แทน

การใช้ Compose นี้ นักพัฒนา Xandros ที่เคยรายงานบั๊กเข้ามา (ตามที่ เล่าไว้ใน blog เก่า) ได้บอกไว้ตอนนั้นว่า เขาแก้ขัดปัญหา SCIM บนโลแคลไทยไป ด้วยการคัดลอกข้อมูล X locale ของ en_US เข้ามาทับของไทย ..ซะงั้น ผมไม่แน่ใจว่าตรงนี้ได้มีการติดต่ออะไรไปที่ต้นน้ำจนมีการใส่ Compose มาใน X locale ไทยตั้งแต่ต้นน้ำหรือเปล่า หรือที่เป็นไปได้อีกอย่าง คือระบบ Makefile ของ libx11 ต้นน้ำนั้น ใช้วิธี include common rule ในทุกโลแคล โดยต้องการให้ทุกโลแคลมีแฟ้ม Compose ทั้งหมด!

จะยังไงก็ตามแต่.. ผมได้รายงานบั๊ก Debian #520509 พร้อมชี้แจงว่า upstream ได้เพิกเฉยต่อบั๊กและแพตช์ต่าง ๆ ที่รายงานไป แต่วิธีแก้แบบนี้ไม่น่าจะถูกต้อง พร้อมกันนั้น ก็ได้ update deb ที่ debclub เอาไว้ด้วย

เรื่องถัดมาที่ทำไป คือเรื่อง extended grapheme cluster ใน Pango กับการเลื่อนเคอร์เซอร์และการลบเซลล์ด้วย Delete (เช่น ใน Mozilla #474068) หลังจากได้ทราบรายละเอียดจาก comment ใน Mozilla แล้ว ก็ตรวจสอบโค้ดของ Pango อีกที และได้ file GNOME #576156 พร้อมเสนอแพตช์แฮ็ก ๆ ไปแพตช์หนึ่ง

เรื่องการ file bug นี้ หยิบขึ้นมาทำก่อน เพราะเป็นเรื่องที่ต้องรอคำตอบ เรา file ไว้แล้วไปทำอย่างอื่นระหว่างรอได้

เรื่องต่อไป คิดว่าจะเป็นเรื่องฟอนต์ เกี่ยวกับปัญหาที่ Davide Viti ได้ ตรวสอบ ไว้

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 ได้พอสมควรทีเดียว

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

My (Partial) TODO List

ชักยาวเป็นหางว่าวแล้ว TODO list ของผม.. แค่ช่วงที่ติดงานแปล GNOME 2.26 นี่เท่านั้น จดไว้กันลืมเสียหน่อย 2.26 ออกเมื่อไรต้องรีบทยอยเคลียร์..

• ออก libdatrie, libthai, swath รุ่นใหม่ที่ได้ ทำค้างเอาไว้
• จัดการเรื่องปัญหา extended cluster ของ pango ซึ่งมีผลกับการเลื่อนเคอร์เซอร์ข้าม cluster ในรูป "เก" และ "กะ" (รวมทั้ง "เกะ") -- สิ่งที่เกี่ยวข้อง: Mozilla #474068, Unicode UAX #29
• ออกแบบเรื่อง UI การใช้ภาษาอังกฤษในโลแคลไทย เพื่อแก้ปัญหา ผู้ใช้ไม่ยอมใช้โลแคลไทย จนไปกระทบ feature ภาษาไทยของระบบ และหาที่เสนอแนวคิด
• แก้ปัญหาเรื่องความกว้างของตัวเลข ตามที่ Davide Viti ได้ ตรวจสอบ เอาไว้ แพกเกจที่กระทบคือ ttf-thai-arundina และ ttf-thai-tlwg
• update Debian package ภาษาไทย โดย update ข้อมูล VCS ของแพกเกจที่ host ที่ LTN จาก CVS เป็น SVN, update ตาม Debian policy 3.8.1, update debhelper เป็น level 7
• ผลักดัน Thai Fonts Siampradesh (non-free) เข้าใน Debian

มีรายการอื่นอีก ที่คงไม่สะดวกที่จะเขียนลง blog เนื่องจากเป็นการติดต่อเป็นการส่วนตัวกับคนอื่น

วันนี้เป็นวันสุดท้ายก่อน tarballs due ของ GNOME 2.26 แล้ว คงจะพยายามแปล user guide ให้ได้มากที่สุด จากนั้นก็เป็นคิวของ release notes ที่ควรจะเสร็จภายในวันพุธ (18 มี.ค.) แล้วหลังจากนั้นถึงจะเป็นอิสระจากงานแปล ไปเคลียร์ TODO list ได้..

Some Thoughts on Translation

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

งานแปลนั้น ที่ผ่านมาก็ได้เจอแนวคิดจากหลายคนเรื่องจะแปลหรือไม่แปลดี ซึ่งเรื่องนี้ก็ไม่ได้เจอเฉพาะภาษาไทย ภาษาอื่น ๆ เขาก็เจอ จึงถือได้ว่าเป็นเรื่องธรรมดา ลองประมวลแนวคิดต่าง ๆ ก็เช่น

pros

• ลด digital divide ยังมีผู้ใช้อยู่มากที่ไม่สามารถใช้ภาษาอังกฤษได้ สำหรับเด็กประถมที่เพิ่งหัดอ่าน ก ข ก กา นี่ยังถือว่าก้ำกึ่ง เพราะแม้เด็กจะรู้ศัพท์ภาษาอังกฤษน้อย แต่ความเป็นเด็กก็ยังพอลองผิดลองถูกในแนวทางของเด็กได้ อีกทั้งงานที่เด็กใช้ก็ยังไม่วิกฤตมาก แต่อีกกลุ่มหนึ่งที่ลืมไม่ได้ คือผู้อาวุโสที่ในรุ่นของท่านยังไม่ได้เน้นเรียนภาษาอังกฤษมาก โดยเฉพาะในต่างจังหวัด หรือแม้แต่เด็กรุ่นใหม่ก็ตาม มีบางสาขาวิชาที่ไม่เคยต้องอ่านตำราภาษาอังกฤษเลย แต่ต้องมาทำงานรูทีนที่ต้องแข่งกับเวลา การมีภาษาไทยเป็นทางเลือก จึงเป็นการอำนวยความสะดวกแก่คนกลุ่มนี้
• กระแสโลกาภิวัตน์ (globalization) ในส่วนเจาะกลุ่มท้องถิ่น พร้อม ๆ กับกระแสที่ทำให้ทั้งโลกเริ่มทำอะไรเหมือน ๆ กันหมด แต่โลกาภิวัตน์ก็มีแนวคิดเรื่องการปรับให้เข้ากับท้องถิ่นด้วย เช่น แมคโดนัลด์ก็มีสูตรกะเพราไก่ หรือจะเป็นเรื่องบังคับอย่างรถยนต์ที่ทำสำหรับประเทศที่วิ่งถนนเลนซ้าย-เลนขวา ซอฟต์แวร์ก็เช่นกัน แนวคิดโลกาภิวัตน์นี้เองที่ทำให้ซอฟต์แวร์เกิดแนวคิด internationalization (I18N) วินโดวส์เลิกทำ Thai Edition, Chinese Edition แล้วเริ่มใช้ I18N มาตั้งแต่ Windows 95 ก็เพื่อเตรียมพร้อมสำหรับการเจาะกลุ่มท้องถิ่นอย่างมีประสิทธิภาพ แนวคิดที่อยู่เบื้องหลังทั้งหมดนี้ ก็คือการปรับตัวในทิศทางย้อนกลับ จากเดิมที่ผู้บริโภคต้องคอยปรับตัวให้เข้ากับส่วนกลาง โลกาภิวัตน์ก็กลับทิศเสียใหม่ ด้วยการให้ส่วนกลางปรับตัวเข้าหาท้องถิ่นด้วย เพื่อความครอบคลุมให้กว้างที่สุด กระแสนี้ทำให้ภาษาท้องถิ่นเริ่มได้รับความสำคัญมากขึ้น คนในยุคโลกาภิวัตน์จึงรู้สึกเท่าเทียมกันมากขึ้นในแง่ภาษา การแปลภาษาจึงเป็นการสะท้อนการตระหนักในความสำคัญของภาษาตนเองอย่างหนึ่ง ท่ามกลางโลกที่ทุกประเทศต่างพร้อมแสดงท่าทีนี้
• เพิ่มความเป็นที่รู้จักของภาษาไทย การที่ภาษาไทยมีการแปลจนขึ้นทำเนียบ supported language นั้น ทำให้ระดับความใส่ใจในการรองรับภาษาไทยของนักพัฒนาส่วนกลางดีขึ้น อันที่จริงแล้ว ในช่วงเริ่มแรกนั้น เราจำเป็นต้องพยายามต่อสู้เอาเองเพื่อให้ได้มาซึ่งการรองรับในระดับโครงสร้างพื้นฐาน เช่น ใน rendering engine และ input method แล้วจึงเริ่มแปลได้ แต่เมื่อแปลแล้ว และ GNOME ได้ประกาศใน release notes ว่าภาษาไทยเป็น supported language แล้ว การร้องขอในเรื่องอื่น ๆ ที่สูงขึ้นไป เช่น การตัดคำ หรือการแก้ปัญหาทั่วไป ก็ย่อมได้รับการตอบรับที่ดีขึ้น หรือแม้แต่ทาง Mozilla ก็เช่นกัน กว่าที่เขาจะรับคำแปลของเราได้ เขาก็ต้องแน่ใจว่าภาษาไทยมีการรองรับโดยพื้นฐานดีพอสมควร แต่การแปลก็ทำให้เกิดความคุ้นเคยบางอย่าง ที่ทำให้เราไม่ต้องรอ check-in แพตช์เป็นปี ๆ เหมือนเมื่อก่อน การแปลเป็นการส่งสัญญาณที่มีประสิทธิภาพอย่างหนึ่ง ว่ามีความต้องการใช้ภาษาไทยเพียงใดในซอฟต์แวร์ของเขา

cons

• ทำให้เด็กไม่กระตือรือร้นเรียนภาษาอังกฤษ แม้ภาษาท้องถิ่นจะมีความสำคัญเพิ่มขึ้นในยุคโลกาภิวัตน์ แต่เวลาที่ติดต่อกับชาวต่างประเทศ ภาษาอังกฤษก็ยังเป็นภาษาที่สะดวกที่สุดอยู่ดี ดังนั้น การแปลข้อความจึงมีผลด้านลบต่อการพัฒนาประเทศ ในแง่ที่ทำให้ประชากรขาดแรงจูงใจ หรือเครื่องมือช่วย ในการเรียนภาษาอังกฤษไปเรื่องหนึ่ง ประเด็นนี้มีนัยสำคัญพอสมควร ดังจะเห็นได้จากการที่เด็กจบใหม่จำนวนมากอ่อนภาษาอังกฤษ หลังจากมีตำราแปลออกมามากมาย การตอบถามปัญหาตามเว็บบอร์ดต่าง ๆ จะเริ่มยุ่งยาก เมื่อผู้ถามต่างเรียกร้องแต่คำตอบภาษาไทย แนะนำลิงก์คำอธิบายภาษาอังกฤษก็โอดครวญ
• แปล doc ดีกว่า อันนี้เป็นบทเสริมของข้อที่แล้ว คือมีบางความเห็น เห็นว่าไม่ควรแปลโปรแกรม แต่แปลเอกสารกับ help ดีกว่า เพื่อช่วยให้คนไทยได้เข้าถึงเทคโนโลยีง่ายเข้า
• ทำให้ผู้ใช้ไทยไม่ใช้โลแคลไทย อันนี้เป็นประเด็นตรงกันข้าม คือเกิดจากผู้ใช้ที่นิยมใช้ UI ภาษาอังกฤษมากกว่าฉบับแปล ..ชอบดูหนังซาวนด์แทร็ก ว่างั้น.. ทำให้เวลาติดตั้งและเข้าระบบ ก็จะเลือกโลแคล en_US ไว้ก่อน ซึ่งผลก็คือ ทำให้ไม่ได้ใช้ส่วนรองรับภาษาไทยที่ขึ้นกับโลแคล เช่น input method และเรื่องอื่น ๆ ที่อาศัยโลแคลเป็นพื้นฐานในการตัดสินใจของโปรแกรม ทำให้การพัฒนาต่าง ๆ เรื่องภาษาไทย แทบจะสูญเปล่า เรื่องนี้ผมก็เคย blog ไว้

ความเห็นของผมเป็นดังนี้:

• ใน blog เรื่องผมเข้าร่วมทีมแปลได้ยังไง ผมได้เล่าไว้ว่า ก่อนที่จะร่วมทีมแปลนั้น ผมไม่เคยเปิดใช้ภาษาไทยเลยเหมือนกัน แต่หลังจากไปเจอกรณีลูกค้าที่ยอมใช้ลินุกซ์ แต่ต้องใช้เมนูภาษาไทย เพราะเขาไม่คล่องภาษาอังกฤษ และต้องการความรวดเร็วในการทำงาน ทำให้ผมต้องเปิดใช้คำแปลภาษาไทยเป็นครั้งแรก และได้รับคำติมามากมายเกี่ยวกับคำแปลที่ขาด ๆ โบ๋ ๆ และใช้ภาษาตลก ๆ ในหลายที่ในตอนนั้น จนนำมาสู่การรายงานปัญหากับทีมแปล และร่วมแปลในแพกเกจที่เจอปัญหา นั่นก็เป็นหลักฐานหนึ่งที่ผมปฏิเสธไม่ได้ ว่า ความต้องการโปรแกรมที่แปลไทยนั้น มีอยู่จริง
• ก่อนที่จะพบกรณีนั้น ผมไม่เคยคิดจะแตะต้องงานแปลเลย เพราะต้องการเน้นงานพัฒนามากกว่า แต่เมื่อได้เปิดใช้เมนูไทยแล้ว ก็พบว่า โปรแกรมที่แปลไม่สมบูรณ์นั้น ให้ความรู้สึกแย่ยิ่งกว่าไม่แปลเลยเสียอีก เพราะจะรู้สึกได้ถึงความไม่เนี้ยบเป็นเนื้อเดียวของเมนูและกล่องโต้ตอบต่าง ๆ ดังนั้น แม้จะไม่พูดถึงว่าควรแปลหรือไม่ แต่ถ้าได้เริ่มแปลแล้ว ควรแปลให้สมบูรณ์
• ประเด็นเรื่องไม่แปลโปรแกรมแต่แปลเฉพาะ help นั้น จะขัดแย้งกันเองในทางปฏิบัติ เพราะโดยทั่วไป วิธีทำงานที่ดีคือ แปลโปรแกรมให้เสร็จ แล้วจึงแปล help เพราะ help จะอ้างถึงเมนู กล่องโต้ตอบต่าง ๆ รวมทั้งภาพหน้าจอตัวอย่าง ถ้าในภายหลังมีการแปลโปรแกรม คุณก็จะต้องไล่แก้ help ทั้งหมดให้ใช้ข้อความตามโปรแกรมด้วยอยู่ดี การที่จะลดความซ้ำซ้อนของงาน จึงควรทำในลำดับกลับกันมากกว่า
• เรื่องการไม่ส่งเสริมการเรียนรู้ภาษาอังกฤษนั้น ผมเห็นด้วยพอสมควร แต่ผมเชื่อว่า การให้ทางเลือกน่าจะดีกว่าอยู่ดี เพราะในบางกรณีเราก็บังคับใช้แต่ภาษาอังกฤษไม่ได้จริง ๆ และเมื่อรวมกับเรื่องผู้ชอบใช้โปรแกรมฉบับไม่แปล ผมก็เห็นว่ายังมีผู้ใช้ที่พยายามจะใช้ภาษาอังกฤษอยู่ดี เพียงแต่จุดบอดของเรื่องนี้ก็คือ ยังขาด UI ที่ดี ในการเลือกภาษาโปรแกรมโดยไม่กระทบกับโลแคลหมวดอื่น ๆ ซึ่งเรื่องนี้ ออกจะ convince นักพัฒนายากสักหน่อย เพราะประเทศพัฒนาแล้ว เขานิยมใช้โปรแกรมฉบับแปลกันเป็นหลัก และเขาก็ถูกทำให้เชื่อในเรื่อง digital divide อย่างฝังลึก เราต้องทำให้เขาเชื่อ ว่าประเทศกำลังพัฒนายังคงต้องการใช้โปรแกรมภาษาอังกฤษอยู่ ก่อนที่จะอภิปรายถึงทางออกต่าง ๆ ต่อไป จุดนี้ ผมคิดว่าจะพยายามหาทางแก้ดู

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

สุดท้าย ก็ขอสรุปลักษณะต่าง ๆ เกี่ยวกับงานแปลในทัศนะของผม:

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

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