วันอาทิตย์ที่ 11 กันยายน 2011
คุณกำลังจะเจาะตลาดโลกและต้องการทำให้เว็บไซต์เข้าถึงได้ในหลายภาษา คุณอาจคิดว่าก็แค่แปลภาษาของเว็บไซต์ ง่ายนิดเดียว แต่อาจจะไม่ง่ายอย่างที่คิดก็ได้ ทีมผู้ดูแลเว็บของ Google สร้างเว็บไซต์ที่แปลเป็นภาษาต่างๆ กว่า 40 ภาษาอยู่บ่อยๆ และมีประเด็นต่างๆ ที่ต้องคำนึงถึงเมื่อเปิดตัวหน้าเว็บในภาษาและภูมิภาคอื่นๆ ซึ่งเราจะมาแชร์กับคุณในครั้งนี้
(แม้คุณจะคิดว่าประเด็นเหล่านี้ไม่น่าจะเป็นปัญหาเพราะคุณนำเสนอเนื้อหาเป็นภาษาอังกฤษเท่านั้น ซึ่งผู้เข้าชมที่ไม่ได้ใช้ภาษาอังกฤษก็อาจใช้เครื่องมืออย่าง Google แปลภาษา เพื่อดูเนื้อหาในภาษาของตน การเข้าชมลักษณะนี้จะแสดงในหน้าแดชบอร์ดข้อมูลวิเคราะห์ เพื่อให้คุณพอจะเห็นภาพว่ามีผู้เข้าชมจำนวนเท่าใดที่ไม่ได้เข้าชมเว็บไซต์ตามลักษณะที่ควรจะเป็น)
เพิ่มภาษาไม่ได้หมายความว่าต้องเพิ่มเทมเพลต HTML ด้วย
เรายังยืนยันที่จะขอแนะนําให้ใช้เทมเพลตเดียวกันสำหรับทุกเวอร์ชันภาษา และพยายามทำให้ HTML ของเทมเพลตเรียบง่ายเสมอ
การทำให้โค้ด HTML เหมือนกันทั้งหมดในทุกภาษามีข้อดีในแง่ของการบํารุงรักษา การแก้ไขข้อบกพร่องของโค้ด HTML ในแต่ละภาษาก็ทำได้ง่าย คุณควรดูแลให้โค้ดของหน้าเว็บสะอาดมากที่สุดเท่าที่จะทำได้ และจัดการกับปัญหาการจัดรูปแบบใน CSS จะขอยกข้อดีของโค้ดที่สะอาดมาสัก 1 ข้อ นั่นคือเครื่องมือแปลส่วนใหญ่จะแยกวิเคราะห์สตริงเนื้อหาที่สามารถแปลได้ออกจากเอกสาร HTML และการทำดังกล่าวจะง่ายขึ้นมากเมื่อเอกสาร HTML มีโครงสร้างที่ดีและถูกต้อง
สตริงหนึ่งๆ ควรจะยาวเท่าไร
หากข้อความในการออกแบบจะแสดงได้อย่างสวยงามเมื่ออยู่บนองค์ประกอบที่มีขนาดคงที่ การแปลข้อความอาจสร้างปัญหาได้ เช่น ข้อความการนําทางด้านซ้ายมือมีแนวโน้มที่จะแปลเป็นสตริงข้อความที่ยาวกว่านั้นในหลายๆ ภาษา ลองดูความแตกต่างของความยาวสตริงระหว่างข้อความการนำทางภาษาอังกฤษกับภาษาดัตช์สำหรับเนื้อหาเดียวกัน ให้ระวังในส่วนชื่อเรื่องของการนําทางที่อาจยาวกว่า 1 บรรทัด โดยคำนวณความสูงของบรรทัดให้รองรับกรณีที่อาจเกิดขึ้นได้นี้ (คุณควรคิดถึงกรณีนี้ด้วยเมื่อสร้างข้อความการนำทางเป็นภาษาอังกฤษในตอนแรก)
ความยาวของคำซึ่งไม่แน่นอนจะทำให้เกิดปัญหาบางอย่างในป้ายกำกับและตัวควบคุมแบบฟอร์ม หากเลย์เอาต์ของแบบฟอร์มแสดงป้ายกำกับทางด้านซ้ายและช่องป้อนข้อมูลอยู่ทางด้านขวา ตัวอย่างเช่น สตริงข้อความที่ยาวกว่าอาจล้นเป็น 2 บรรทัด ในขณะที่สตริงข้อความที่สั้นกว่าก็ทำให้ดูไม่เชื่อมโยงกับช่องป้อนข้อมูลของแบบฟอร์ม ทั้ง 2 กรณีนี้จะทำให้เลย์เอาต์เสียและการอ่านแบบฟอร์มไม่ลื่นไหล นอกจากนี้ ให้พิจารณาการจัดรูปแบบเพิ่มเติมที่คุณจะต้องใช้สำหรับเลย์เอาต์แบบอ่านจากขวาไปซ้าย (RTL) ด้วย (จะพูดถึงรายละเอียดเพิ่มเติมในภายหลัง) ด้วยเหตุผลเหล่านี้ เราจึงออกแบบแบบฟอร์มให้ป้ายกำกับอยู่เหนือช่องป้อนข้อมูล เพื่อให้ง่ายต่อการอ่านและการจัดรูปแบบ และไม่เกิดปัญหาเมื่อแปลเป็นภาษาต่างๆ
นอกจากนี้ ให้หลีกเลี่ยงการสร้างคอลัมน์ที่มีความสูงคงที่หากคุณพยายามปรับเลย์เอาต์ให้เป็นระเบียบขึ้นโดยใช้พื้นหลังเป็นกล่องที่ความสูงเท่ากัน เพราะเมื่อแปลข้อความแล้วอาจมีโอกาสที่ข้อความจะอยู่เฉพาะในพื้นที่ที่มีความสูงมากพอสำหรับเนื้อหาภาษาอังกฤษ ให้คิดถึงว่าองค์ประกอบ UI ที่คุณวางแผนจะใช้ในการออกแบบจะใช้ได้ดีหรือไม่เมื่อมีข้อความมากขึ้นหรือน้อยลง เช่น แท็บในแนวนอนเทียบกับแท็บในแนวตั้ง
ไม่ใช่ทุกภาษาที่อ่านจากซ้ายไปขวา
การแก้ไขภาษาต้นฉบับสำหรับ HTML ที่เป็นแบบ 2 ทิศทาง (bidirectional) อาจเป็นปัญหาได้เนื่องจากเครื่องมือแก้ไขจำนวนมากไม่ได้ออกแบบมาเพื่อรองรับอัลกอริทึมแบบ 2 ทิศทางของ Unicode (ดูการวิจัยเพิ่มเติมเกี่ยวกับปัญหาและทางออก) กล่าวโดยสรุปคือมาร์กอัปของคุณอาจแสดงในลักษณะที่ไม่ถูกต้องเช่นตัวอย่างด้านล่างนี้
<p>
ابةتث
<img src="foo.jpg" alt=" جحخد" />
< ذرزسش!
</p>
จากการใช้งานในทุกๆ วันของเราแสดงให้เห็นว่าเครื่องมือแก้ไขต่อไปนี้ โดยเฉพาะ Coda รวมถึง Dreamweaver, IntelliJ IDEA และ JEditX เป็นทางออกที่ดีสำหรับการแก้ไขแบบ 2 ทิศทาง
เมื่อออกแบบเลย์เอาต์ที่อ่านจากขวาไปซ้าย คุณสามารถสร้างการรองรับส่วนใหญ่ที่ต้องใช้ไว้ใน CSS หลัก และใช้แอตทริบิวต์ทิศทาง (directional) ขององค์ประกอบ html (สำหรับความเข้ากันได้แบบย้อนหลัง) ร่วมกับคลาสในองค์ประกอบ body และเช่นเคย การเก็บรูปแบบทั้งหมดไว้ในไฟล์สไตล์ชีตหลักไฟล์เดียวจะช่วยให้ทำการบํารุงรักษาได้ดีกว่า
ปัญหาหลักๆ ของการจัดรูปแบบที่ควรระวังคือ เมื่อองค์ประกอบที่ลอยอยู่ทางขวาจะต้องไปลอยอยู่ทางซ้ายและในทางกลับกัน เมื่อต้องลบล้างหรือสลับความกว้างของระยะห่างจากขอบส่วนเกินที่ใช้กับด้านใดด้านหนึ่งขององค์ประกอบ และเมื่อต้องมีการกลับด้านแอตทริบิวต์การจัดแนวข้อความ
โดยทั่วไปเราจะใช้วิธีการต่อไปนี้ รวมถึงการใช้คลาสในแท็กเนื้อหา (body) แทนที่จะใช้ตัวเลือก CSS html[dir=rtl] เพราะจะเข้ากันได้กับเบราว์เซอร์รุ่นเก่า
องค์ประกอบ
<body class="rtl">
<h1>
<a href="https://www.blogger.com/">
<img alt="Google" src="https://www.google.com/images/logos/google_logo.png" />
</a> Heading
</h1>
การจัดรูปแบบจากซ้ายไปขวา (ค่าเริ่มต้น)
h1 {
height: 55px;
line-height: 2.05;
margin: 0 0 25px;
overflow: hidden;
}
h1 img {
float: left;
margin: 0 43px 0 0;
position: relative;
}
การจัดรูปแบบจากขวาไปซ้าย
body.rtl {
direction: rtl;
}
body.rtl h1 img {
float: right;
margin: 0 0 0 43px;
}
(ดูการทำงานจริงในภาษาอังกฤษและอาหรับ)
ข้อควรจำสุดท้ายเกี่ยวกับเรื่องนี้คือ ส่วนใหญ่แล้วเนื้อหาที่แปลเป็นภาษาแบบอ่านจากขวาไปซ้ายจะเป็นแบบแก้ไขได้ 2 ทิศทางมากกว่าจะเป็นแบบขวาไปซ้ายเพียงอย่างเดียว เพราะบางสตริงอาจยังต้องรักษาทิศทางแบบซ้ายไปขวาไว้ เช่น ชื่อบริษัทในตัวเขียนภาษาละตินหรือหมายเลขโทรศัพท์ เป็นต้น วิธีที่จะช่วยให้แน่ใจว่าเบราว์เซอร์จะจัดการเรื่องนี้ได้อย่างถูกต้องในเอกสารที่อ่านจากขวาไปซ้ายเป็นหลักคือ ให้รวมสตริงข้อความที่ฝังกับองค์ประกอบในบรรทัดโดยใช้แอตทริบิวต์เพื่อกำหนดทิศทาง ดังตัวอย่างต่อไปนี้
<h2>עוד ב- <span dir="ltr">Google</span></h2>
ในกรณีที่คุณไม่มีคอนเทนเนอร์ HTML ที่จะเชื่อมโยงกับแอตทริบิวต์ทิศทาง (dir) เช่น องค์ประกอบของชื่อเรื่อง หรือซอร์สโค้ดที่สร้างจาก JavaScript สำหรับข้อความแจ้ง คุณสามารถใช้ค่าที่เทียบเท่าเพื่อระบุทิศทางที่ ‫ และ ‬ เป็นอักขระควบคุม Unicode สำหรับการฝังจากขวาไปซ้าย ดังนี้
<title>‫הפוך את Google לדף הבית שלך‬</title>
ตัวอย่างการใช้โค้ด JavaScript
var ffError = '\u202B' +'כדי להגדיר את Google כדף הבית שלך ב\x2DFirefox, לחץ על הקישור \x22הפוך את Google לדף הבית שלי\x22, וגרור אותו אל סמל ה\x22בית\x22 בדפדפן שלך.'+ '\u202C';
(ดูรายละเอียดเพิ่มเติมได้จากบทความของ W3C เรื่องการสร้าง HTML สำหรับภาษาอาหรับ ฮีบรู และภาษาที่อ่านจากขวาไปซ้ายอื่นๆ และการเขียนโค้ดสำหรับภาษาที่อ่านจากขวาไปซ้าย)
เมื่อผลลัพธ์ไม่เป็นตามที่ต้องการ
หากคุณไม่เคยเข้ารหัสข้อความที่ไม่ใช่ภาษาละตินมาก่อน (ซีริลลิก กรีก รวมถึงภาษาเอเชียและอินเดียจำนวนมาก) คุณอาจพบว่าทั้งเครื่องมือแก้ไขและเบราว์เซอร์ไม่แสดงเนื้อหาตามที่ตั้งใจ
โปรดตรวจสอบว่าการเข้ารหัสของตัวแก้ไขและเบราว์เซอร์ตั้งค่าเป็น UTF-8 (แนะนํา) จากนั้นพิจารณาเพิ่มองค์ประกอบ <span> และแอตทริบิวต์ lang ขององค์ประกอบ html ลงในเทมเพลต HTML เพื่อให้เบราว์เซอร์รู้ว่าจะต้องแสดงผลหน้าเว็บของคุณแบบไหน วิธีนี้จะเป็นประโยชน์เพราะอักขระ Unicode ทั้งหมดจะแสดงผลอย่างถูกต้อง ดังนั้น จึงไม่จำเป็นต้องใช้เอนทิตี HTML อย่าง é (é) และช่วยประหยัดไบต์ไปได้อีกมาก หากพบปัญหา โปรดอ่านบทแนะนําของ W3C เกี่ยวกับการเข้ารหัสอักขระ โดยในบทความมีคำอธิบายโดยละเอียดเกี่ยวกับปัญหาต่างๆ
เกี่ยวกับการตั้งชื่อ
สุดท้าย ขอแนะนำเคล็ดลับที่ใช้ได้จริงสำหรับรูปแบบการตั้งชื่อเมื่อสร้างหน้าเว็บในเวอร์ชันภาษาต่างๆ การใช้มาตรฐาน เช่น รหัสภาษา ISO 639-1 สำหรับการตั้งชื่อจะเป็นประโยชน์เมื่อคุณเริ่มต้นจัดการกับเอกสารเดียวกันที่แปลเป็นหลายภาษา
การใช้มาตรฐานที่เป็นแบบแผนจะช่วยให้ผู้ใช้เข้าใจโครงสร้างเว็บไซต์ของคุณ และทำให้ผู้ดูแลเว็บทุกคนที่ร่วมพัฒนาเว็บไซต์ช่วยกันบำรุงรักษาได้ง่ายกว่า และการใช้รหัสภาษาสำหรับเนื้อหาอื่นๆ ในเว็บไซต์ (เช่น รูปภาพโลโก้ เอกสาร PDF) ก็สามารถระบุไฟล์ได้อย่างสะดวกรวดเร็ว
โปรดดูโพสต์ก่อนหน้าของ Webmaster Central สำหรับคำแนะนําเรื่องโครงสร้าง URL และปัญหาอื่นๆ เกี่ยวกับการทำงานกับเว็บไซต์หลายภูมิภาคและการทำงานกับเว็บไซต์หลายภาษา
และนี่คือข้อมูลสรุปเกี่ยวกับภารกิจหลักที่เราทำในแต่ละวัน อย่างไรก็ตาม หากคุณวางแผนและทุ่มเทให้กับการวางโครงสร้าง HTML ที่ดีและสร้าง CSS ที่มีประสิทธิภาพ เรารับรองได้ว่าคุณจะได้ผลตอบแทนที่คุ้มค่าเมื่อทำการแปลเว็บไซต์