3 คะแนน โดย GN⁺ 2023-08-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ใช้เพียง แอตทริบิวต์ dir="auto" ของ HTML ก็สามารถรองรับ ภาษา RTL (ขวาไปซ้าย) เช่น ฮีบรู อาหรับ และอูรดู ได้อัตโนมัติในช่องกรอกข้อมูลและพื้นที่ข้อความ
  • ก่อนหน้านี้มักมีการแนะนำแต่ วิธีแบบแมนนวลและซับซ้อน เช่น เขียนลิสเนอร์ตรวจจับตัวอักษร ใช้ไลบรารีภายนอก หรือสลับเป็น dir="right" ด้วยตนเอง
  • ในผลการค้นหา "textarea rtl" ไม่มีที่ไหนพูดถึง dir="auto" เลย ทำให้ เข้าใจผิดว่าเป็นปัญหาที่ต้องแก้เองโดยตรง มาตลอด
  • เมื่อลองใช้งานจริง กลับ ทำงานได้ถูกต้องทันที โดยไม่ต้องพาร์สภาษาระดับล่างเพิ่มเติม
  • แม้จะเป็นการเปลี่ยนแปลงเล็กน้อย แต่ส่งผลมาก และเป็น องค์ประกอบสำคัญของการทำ internationalization (i18n) ที่ชี้วัดว่าผู้ใช้ทั่วโลกจะใช้งานแอปได้หรือไม่

ความยากของการรองรับ RTL

  • ตั้งแต่ช่วงแรกของ Standard Notes ก็มีคำขอให้รองรับ ภาษา RTL เช่น ฮีบรู อาหรับ และอูรดู เข้ามา แต่ถูกเลื่อนมาตลอดเพราะดูเหมือนว่าจะทำได้ยาก
  • ทุกครั้งที่พิจารณา ปัญหานี้ดูเหมือนต้องทำ งานพาร์สภาษา ที่ต้องจัดการเรื่อง encoding ระดับล่างอย่าง Unicode และ ASCII จึงหลีกเลี่ยงมาตลอด
  • แม้หัวข้อนี้จะกลับมาซ้ำทุกไม่กี่เดือน แต่คำแนะนำที่ได้รับก็มีแต่แบบเดิมทุกครั้ง
    • เขียนตัวพาร์สอักขระเอง
    • ใช้ไลบรารีภายนอก
    • ใช้ dir="right"

ข้อจำกัดของการค้นหา

  • ต่อให้ค้นหาด้วยคำอย่าง "textarea rtl" หรือ "textarea right to left" ก็ ไม่พบ dir="auto" ในผลลัพธ์เลย
  • สิ่งที่เจอมีแต่คำตอบบน Stack Overflow ที่บอกให้ใส่ dir="rtl" ในแท็ก หรือไลบรารีภายนอกของ Twitter
  • เพราะเชื่อแค่ผลลัพธ์หน้าแรกของการค้นหา จึง ด่วนสรุปว่าเป็นปัญหาที่ต้องลงมือแก้เอง และถูกเลื่อนลำดับความสำคัญออกไปเรื่อย ๆ

การค้นพบวิธีแก้

  • เมื่อไม่กี่สัปดาห์ก่อน ระหว่างค้นหาอีกครั้ง ได้เจอคอมเมนต์ในโพสต์บน GitHub ที่บอกว่า "แค่เพิ่ม dir="auto" ให้กับ textarea ก็พอ"
  • ปัญหาที่หาคำตอบมานาน 1 ปี ถูกแก้ได้ด้วยโค้ดเพียงบรรทัดเดียว
  • เมื่อลองนำไปใช้จริง ผลคือ ทำงานได้อย่างสมบูรณ์โดยไม่มีข้อบกพร่อง

วิธีนำไปใช้

  • เพิ่มแอตทริบิวต์เพียงบรรทัดเดียวในช่องกรอกข้อมูลหรือพื้นที่ข้อความ
    • <textarea dir='auto'> שלום, עתיד. </textarea>
  • ทิศทางข้อความจะ ถูกตรวจจับโดยอัตโนมัติ ตามค่าที่ผู้ใช้ป้อน
  • เอกสาร MDN ของแอตทริบิวต์ dir มีคำอธิบายที่เกี่ยวข้องไว้ด้วย

1 ความคิดเห็น

 
GN⁺ 2023-08-24
ความเห็นจาก Hacker News
  • เป็นวิธีง่าย ๆ ในการแก้ การเรนเดอร์ข้อความ ของช่องกรอกและ textarea ก็จริง แต่ต้องจัดการแบบเดียวกันกับองค์ประกอบที่ใช้แสดงข้อความที่ส่งมาแล้วด้วย
    และพอเจอข้อความสองทิศทาง เช่น ชื่อผลิตภัณฑ์ภาษาอังกฤษอยู่ในย่อหน้าภาษาอาหรับ ระดับความซับซ้อนก็เปลี่ยนไปอีกแบบเลย
    ตอนนี้ Chrome มี regression bug ที่ส่งผลต่อการเรนเดอร์ข้อความ RTL ในช่องกรอกที่มี dir='auto' อยู่ แต่มีการปล่อยแพตช์แก้แล้วและน่าจะรวมอยู่ในรีลีสถัดไป

  • MDN ช่วยไว้ได้เสมอ: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

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

    • ผมนึกถึงเรื่องนี้ทุกครั้งเวลาคิดว่าจะรองรับภาษาอื่นในโปรเจกต์ส่วนตัวดีไหม
      ลองค้นเร็ว ๆ ก็เห็นว่ามี ผู้ใช้ภาษาอังกฤษราว 840 ล้านคน ซึ่งถ้าทำคนเดียว การเข้าถึงได้แค่ 1/10 ของโลกก็ดูไม่ได้แย่อะไร
      การขยายขอบเขตเพื่อรองรับคนให้มากขึ้นเป็นเรื่องดี แต่ไม่ใช่สิ่งที่จำเป็นต้องทำเสมอไป
    • ถ้าการรองรับ กรณีใช้งานเฉพาะทาง ทำได้ง่ายและภาระดูแลรักษาน้อย ก็ใส่มาเล่น ๆ ก็ยังได้
  • บอกว่า “หน้าผลลัพธ์แรกของ Google ไม่เคยโกหก” งั้นเหรอ มีเรื่องจะเล่าที่ช่วยแก้ปัญหาได้อยู่หรอก แต่ควรนั่งลงก่อน เพราะน่าจะทำให้เศร้า

    • ดูเหมือนจะตีความประโยคนั้นแบบตรงตัวเกินไป
      คำว่า “หน้าผลลัพธ์แรกของ Google ไม่เคยโกหก…” แทบจะแน่ใจได้ว่าเป็น การประชด จากประโยคต่อมาที่ว่า “Google โกหกเราเรื่องการรองรับ RTL ของช่องกรอกมาโดยตลอด”
  • น่าเสียดายที่ทั้งเว็บไซต์และ CodePen ที่ลิงก์ไว้ การเรนเดอร์ซอร์ส ค่อนข้างเละ ตำแหน่งของจุด full stop ผิด แต่ HTML ที่เรนเดอร์ออกมาถูกต้อง
    ดูเหมือนว่านี่จะเป็นอีกครั้งที่อัลกอริทึมข้อความสองทิศทางของ Unicode ทำงานไม่เข้าเป้า
    น่าจะต้องมีอัลกอริทึมพิเศษที่เรนเดอร์ HTML tag ทั้งก้อนระหว่าง < กับ > เป็นหน่วยอะตอมที่ภายในเป็น LTR แต่ไม่ไปรบกวนทิศทางของอักขระรอบข้าง
    ในตัวอย่างนี้ อัลกอริทึมควรจะสามารถสลับทิศทางตรงกลางของลำดับ .< ได้

    • ตรงนี้ อัลกอริทึมข้อความสองทิศทางของ Unicode ไม่ได้ล้มเหลว แต่กำลังทำงานตามที่ออกแบบไว้
      ทิศทางตั้งต้นของชิ้นส่วนซอร์สโค้ดเป็น LTR แต่มีข้อความภาษาฮีบรูทำให้เกิดการผสมทิศทาง
      เครื่องหมายวรรคตอนมีทิศทางแบบอ่อน ดังนั้นจุด full stop จึงไปอยู่ท้ายช่วง RTL และเพราะทิศทางตั้งต้นเป็น LTR คำว่า “ท้าย” ตรงนี้จึงหมายถึงด้านขวา
      ถ้าจะบังคับให้คอนเทนต์ที่มีทิศทางผสมเรนเดอร์ได้ถูกต้อง มักต้องใส่อักขระควบคุม BiDi เพื่อระบุว่าช่วงทิศทางเฉพาะเริ่มและจบตรงไหน
      แต่ในกรณีนี้การใส่แบบนั้นกลับอาจทำให้การเรนเดอร์ตัวอย่างอินพุตจริงเสียได้ จึงไม่ควรใส่
  • ที่เกี่ยวข้องกันคือ ช่วงไม่กี่ปีมานี้การรองรับ logical properties/values เริ่มสมบูรณ์ขึ้นมาก
    สิ่งนี้เป็นทางเลือกแทนพร็อพเพอร์ตีที่อิงทิศทางอย่าง top/left/bottom/right และสามารถปรับตามคอนเทนต์หรือทิศทางของข้อความได้
    https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_logical...

    • แนวคิดแบบนี้เป็นมาตรฐานบนแพลตฟอร์มมือถือมานานแล้ว อย่างเช่น leading กับ trailing ของ iOS
      ดีที่มันเข้ามาอยู่บนเว็บด้วย และทำให้การสร้าง UI ที่ไม่ผูกกับภาษา เป็นเรื่องที่เป็นไปได้จริงขึ้นมาก
  • ถ้าค้นหา textarea กับข้อความ BiDi ในแทบทุกแบบที่ผมนึกออก https://www.w3.org/International/talks/1602-oman จะเป็นหนึ่งในลิงก์ต้น ๆ
    ในหน้านั้นก็มีหัวข้อ “What if you don't know the direction in advance” อยู่ตรงประเด็นเลย: https://www.w3.org/International/talks/1602-oman/#advance
    ปัญหาคือดูเหมือนผู้เขียนจะไม่ค่อยคุ้นกับเรื่องนี้ เลยไม่รู้ด้วยซ้ำว่าคำค้นที่ถูกต้องคือ BiDi ซึ่งเป็นคำย่อของ “bi-directional text” และใช้เมื่อไม่อยากระบุทิศทางการเขียนแบบตายตัว
    ผมก็ไม่อยากโทษที่เขาคิดว่า “ผลการค้นหามันผิด” นะ เพราะถ้าค้นด้วย RTL คำตอบที่ออกมาก็ถือว่าถูก แต่คุณจะไม่รู้เรื่องนี้จนกว่าจะเข้าใจสาขานี้มากกว่านี้หน่อย
    มันสะท้อนข้อจำกัดของการพึ่งคำตอบจากอินเทอร์เน็ต อินเทอร์เน็ตไม่รู้ว่าผมไม่รู้อะไร
    ถ้าไปถามคนที่ทำ BiDi มานาน คำถามแรก ๆ ที่น่าจะได้ยินคือ “คุณกำลังพูดถึง RTL หรือ BiDi?”
    ถ้าทำได้ การถามคนย่อมดีกว่าถามซอฟต์แวร์ โดยเฉพาะเมื่อคุณยังไม่คุ้นกับเรื่องนั้น

    • แทนที่จะใช้คำย่อเฉพาะวงการมาทำตัวเป็นคนเฝ้าประตูความรู้แล้วกดผู้เขียนลง อาจมองในแง่ดีได้ว่าอย่างน้อยเขาก็ช่วยทำให้ปัญหานี้เป็นที่รับรู้มากขึ้น
  • อีกอย่างที่ควรเพิ่มลิงก์ไว้คือ dirname ซึ่งเป็นแอตทริบิวต์น่าสนใจที่สามารถแนบ ทิศทางของข้อความ ไปพร้อมกับการส่งฟอร์มได้: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...

  • ถ้าผมทำเบราว์เซอร์ ผมอยากประกาศเพื่อประโยชน์สาธารณะว่า ถ้าไม่ได้ระบุอะไรเป็นพิเศษก็ให้ถือเป็น dir="auto"

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

    • โอ้ เจ๋งดีแฮะ แล้วพอลองพิมพ์ภาษาอังกฤษแบบนั้นก็สนุกกว่าที่คิดอีก ผมลองเล่นอยู่นานกว่าที่ควรเลย
    • ใน Vim รุ่นเก่า ๆ ยังมี vim -A ที่เริ่มด้วย โหมดภาษาอาหรับ ด้วย ไม่รู้ว่าใช้งานยังไง เหมือนจะเกี่ยวกับการใช้ input method บางอย่าง
    • แล้ว :set td ล่ะ?