การทำให้เป็นสากลและการแปลเป็นภาษาท้องถิ่นสำหรับไซต์คงที่

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

เมื่อสร้าง chromeOS.dev ขึ้นมา เรารู้ว่าเราต้องให้บริการแก่ผู้ชมทั่วโลก ตรวจสอบให้แน่ใจว่า codebase ของเราสามารถสนับสนุนหลายภาษา (ภาษา ภูมิภาค หรือทั้งสองอย่างรวมกัน) โดยไม่ต้องกำหนดรหัสเองแต่ละอัน ในขณะที่อนุญาตให้การแปลทำได้โดยใช้ความรู้ของระบบนั้นน้อยที่สุดเท่าที่จะเป็นไปได้ เป็นสิ่งสำคัญที่จะทำให้ สิ่งนี้เกิดขึ้น ผู้สร้างเนื้อหาของเราจำเป็นต้องสามารถมุ่งเน้นไปที่การสร้างเนื้อหา และนักแปลของเราในการแปลเนื้อหา โดยทำงานให้น้อยที่สุดเท่าที่จะทำได้เพื่อนำงานของพวกเขามาไว้ในไซต์และนำไปใช้งาน การทำให้ชุดความต้องการที่ขัดแย้งกันในบางครั้งถูกต้องเป็นหัวใจสำคัญของการทำให้ codebases เป็นสากลและโลคัลไลซ์ไซต์

การทำให้เป็นสากล (i18n) และการแปลเป็นภาษาท้องถิ่น (l10n) เป็นสองด้านของเหรียญเดียวกัน การทำให้เป็นสากลคือทั้งหมดที่เกี่ยวกับการออกแบบซอฟต์แวร์ ในกรณีของเรา เพื่อให้สามารถปรับให้เข้ากับภาษาและภูมิภาคได้หลายภาษาโดยไม่ต้องมีการเปลี่ยนแปลงทางวิศวกรรม ในทางกลับกัน Localization เป็นเรื่องเกี่ยวกับการปรับซอฟต์แวร์สำหรับภาษาและภูมิภาคเหล่านั้น การทำให้เป็นสากลสามารถเกิดขึ้นได้ทั่วทั้งเว็บไซต์ ตั้งแต่ HTML, CSS และ JS ไปจนถึงข้อควรพิจารณาในการออกแบบและสร้างระบบ การโลคัลไลเซชันเกิดขึ้นส่วนใหญ่ในการสร้างเนื้อหา (ทั้งสำเนาแบบยาวและไมโครสำเนา) และการจัดการ

หมายเหตุ : สำหรับผู้ที่อยากรู้อยากเห็น i18n และ l10n เป็นคำย่อประเภทหนึ่งที่เรียกว่า numeronyms A11y สำหรับการช่วยสำหรับการเข้าถึง เป็นอีกชื่อหนึ่งที่ใช้กันทั่วไปในการพัฒนาเว็บ

การทำให้เป็นสากล (i18n)

ในการค้นหาความเป็นสากล โดยทั่วไปมีสามสิ่งที่คุณต้องพิจารณา: วิธีค้นหาภาษาและ/หรือภูมิภาคที่ผู้ใช้ต้องการ วิธีตรวจสอบให้แน่ใจว่าพวกเขาได้รับเนื้อหาในภาษาที่ต้องการ และวิธีปรับไซต์ของคุณเพื่อปรับให้เข้ากับ ความแตกต่างเหล่านั้น แม้ว่าการใช้งานเฉพาะอาจเปลี่ยนแปลงได้สำหรับไซต์แบบไดนามิก (ที่แสดงหน้าเว็บเมื่อผู้ใช้ร้องขอ) และไซต์แบบคงที่ (ซึ่งสร้างหน้าเว็บก่อนที่จะปรับใช้) แนวคิดหลักควรคงเดิม

การกำหนดภาษาและภูมิภาคของผู้ใช้

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

โดยทั่วไป มีสามวิธีระดับสูงในการพิจารณาว่าการแปลเป็นภาษาท้องถิ่นใดที่จะให้บริการแก่ผู้ใช้:

1. ตำแหน่งจากที่อยู่ IP;
2. Accept-Language หรือ navigator.languages ​​;
3. ตัวระบุใน URL

หลายระบบจบลงที่การรวมหนึ่ง สอง หรือทั้งสามเข้าด้วยกัน เมื่อตัดสินใจว่าจะให้บริการโลคัลไลเซชันใด ในขณะที่เรากำลังตรวจสอบ เราพบปัญหาเกี่ยวกับการใช้ที่อยู่ IP และส่วนหัว Accept-Language ซึ่งเราคิดว่ามีความสำคัญมากพอที่จะลบออกจากการพิจารณาสำหรับเรา:

• ภาษาที่ผู้ใช้ต้องการมักไม่สัมพันธ์กับตำแหน่งทางกายภาพ ซึ่งที่อยู่ IP ให้มา ตัวอย่างเช่น เพียงเพราะมีคนอาศัยอยู่ในอเมริกา ไม่ได้หมายความว่าพวกเขาต้องการเนื้อหาภาษาอังกฤษ
• การวิเคราะห์ตำแหน่งจากที่อยู่ IP นั้นทำได้ยาก โดยทั่วไปแล้วไม่น่าเชื่อถือ และอาจป้องกันไม่ให้เครื่องมือค้นหารวบรวมข้อมูลเว็บไซต์
• ส่วนหัว Accept-Language มักไม่มีการตั้งค่าไว้อย่างชัดเจน และให้ข้อมูลเกี่ยวกับภาษาเท่านั้น ไม่ใช่ภูมิภาค เนื่องจากข้อจำกัด การทำเช่นนี้อาจเป็นประโยชน์ในการคาดเดาเบื้องต้นเกี่ยวกับภาษา แต่ไม่จำเป็นต้องเชื่อถือได้เสมอไป

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

มีรูปแบบทั่วไปสามรูปแบบสำหรับการสร้างตัวระบุลงใน URL:

1. ระบุโดเมนที่แตกต่างกัน (โดยปกติคือ TLD หรือโดเมนย่อยสำหรับภูมิภาคและภาษาต่างๆ (เช่น example.com และ example.de , en.example.org และ de.example.org )
2. มีไดเร็กทอรีย่อยที่แปลสำหรับเนื้อหา (เช่น example.com/en และ example.com/de );
3. ให้บริการเนื้อหาที่แปลตามพารามิเตอร์ของ URL (เช่น example.com?loc=en และ example.com?loc=de )

แม้ว่าจะใช้กันทั่วไป แต่โดยทั่วไปแล้ว พารามิเตอร์ของ URL จะไม่แนะนำ เนื่องจากเป็นการยากสำหรับผู้ใช้ที่จะรู้จักการแปลเป็นภาษาท้องถิ่น (พร้อมกับปัญหาด้านการวิเคราะห์และการจัดการจำนวนหนึ่ง) เรายังตัดสินใจว่าโดเมนที่ต่างกันไม่ใช่ทางออกที่ดีสำหรับเรา ไซต์ของเราคือ Progressive Web App และทุกโดเมน รวมถึง TLD และโดเมนย่อย ถือเป็นแหล่งกำเนิดที่แตกต่างกัน ซึ่งจำเป็นต้องมี PWA แยกจากกันสำหรับการแปลแต่ละครั้ง

เราตัดสินใจใช้ไดเร็กทอรีย่อย ซึ่งให้โบนัสแก่เราในการแปลเป็นภาษาท้องถิ่นเท่านั้น ( example.com/en ) หรือภาษาและภูมิภาค ( example.com/en-US และ example.com/en-GB ) ตามความจำเป็นในขณะที่ รักษา กปภ. แห่งเดียว เรายังตัดสินใจด้วยว่าการโลคัลไลเซชั่นของไซต์ของเราทุกครั้งจะอยู่ในไดเร็กทอรีย่อย ดังนั้นภาษาหนึ่งจะไม่ถูกยกระดับเหนืออีกภาษาหนึ่ง และ URL ทั้งหมด ยกเว้นสำหรับไดเร็กทอรีย่อย จะเหมือนกันในการแปลตามภาษาที่เขียน ทำให้ผู้ใช้สามารถเปลี่ยนแปลงได้อย่างง่ายดาย การแปลโดยไม่ต้องแปล URL

ให้บริการเนื้อหาที่แปลแล้ว

เมื่อกำหนดกลยุทธ์ในการกำหนดภาษาและภูมิภาคของผู้ใช้แล้ว คุณต้องมีวิธีให้บริการเนื้อหาที่เหมาะสมกับผู้ใช้อย่างน่าเชื่อถือ อย่างน้อยที่สุด ข้อมูลนี้จะต้องใช้ข้อมูลที่เก็บไว้บางรูปแบบ ไม่ว่าจะเป็นในคุกกี้ พื้นที่จัดเก็บบางส่วน หรือส่วนหนึ่งของตรรกะที่กำหนดเองของแอป ความสามารถในการรักษาการตั้งค่าการโลคัลไลเซชันของผู้ใช้เป็นส่วนสำคัญของประสบการณ์ผู้ใช้ i18n; หากผู้ใช้ระบุว่าพวกเขาต้องการเนื้อหาในภาษาเยอรมันและเข้าสู่เนื้อหาภาษาอังกฤษ คุณควรจะสามารถระบุภาษาที่ต้องการและเปลี่ยนเส้นทางได้อย่างเหมาะสม สามารถทำได้บนเซิร์ฟเวอร์ แต่โซลูชันที่เราใช้กับ chromeOS.dev คือการโฮสต์และการตั้งค่าเซิร์ฟเวอร์ที่ไม่เชื่อเรื่องพระเจ้า: เราใช้พนักงานบริการ การเดินทางของผู้ใช้มีดังนี้:

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

เรารวมโซลูชันของเราไว้ในปลั๊กอิน Workbox, Service Worker Internationalization Redirect ปลั๊กอินพร้อมกับโมดูลย่อยการกำหนดค่าตามความชอบสามารถรวมกันเพื่อตั้งค่าและรับการตั้งค่าภาษาของผู้ใช้และจัดการการเปลี่ยนเส้นทางเมื่อรวมกับเมธอด registerRoute ของ Workbox และการกรองคำขอตามต้องการ request.mode === 'navigate'

ตัวอย่างที่สมบูรณ์และน้อยที่สุดมีลักษณะดังนี้:

รหัสลูกค้า

 import { preferences } from 'service-worker-i18n-redirect/preferences'; window.addEventListener('DOMContentLoaded', async () => { const language = await preferences.get('lang'); if (language === undefined) { preferences.set('lang', lang.value); // Language determined from localization user landed on } });

รหัสพนักงานบริการ

 import { StaleWhileRevalidate } from 'workbox-strategies'; import { CacheableResponsePlugin } from 'workbox-cacheable-response'; import { i18nHandler } from 'service-worker-i18n-redirect'; import { preferences } from 'service-worker-i18n-redirect/preferences'; import { registerRoute } from 'workbox-routing'; // Create a caching strategy const htmlCachingStrategy = new StaleWhileRevalidate({ cacheName: 'pages-cache', plugins: [ new CacheableResponsePlugin({ statuses: [200], }), ], }); // Array of supported localizations const languages = ['en', 'es', 'fr', 'de', 'ko']; // Use it for navigations registerRoute( ({ request }) => request.mode === 'navigate', i18nHandler(languages, preferences, htmlCachingStrategy), );

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

การปรับส่วนต่อประสานผู้ใช้ของไซต์

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

คำคมบล็อค

รูปแบบการออกแบบทั่วไปมี blockquotes ที่ห่อด้วยเครื่องหมายคำพูด แต่คุณทราบหรือไม่ว่าสิ่งที่จะใช้สำหรับเครื่องหมายคำพูดเหล่านั้นแตกต่างกันไปตามการแปล แทนที่จะใช้ฮาร์ดโค้ด ให้ใช้ open-quote และ close-quote เพื่อให้แน่ใจว่ามีการใช้เครื่องหมายคำพูดที่ถูกต้องสำหรับภาษาที่ถูกต้อง

รูปแบบวันที่และตัวเลข

วันที่และตัวเลขทั้งสองมีวิธีการ . .toLocaleString เพื่ออนุญาตการจัดรูปแบบตามการแปล (ภาษาและ/หรือภูมิภาค) เบราว์เซอร์ที่รองรับการจัดส่งเหล่านี้พร้อมการแปลเป็นภาษาท้องถิ่นทั้งหมด ทำให้ใช้งานได้ทันที แต่ Node.js ไม่สามารถทำได้ โชคดีที่โมดูล full-icu สำหรับ Node ช่วยให้คุณใช้ข้อมูลการโลคัลไลเซชันทั้งหมดที่มีได้ หลังจากติดตั้งโมดูลแล้ว ให้รันโค้ดของคุณโดยตั้งค่าตัวแปรสภาพแวดล้อม NODE_ICU_DATA เป็นพาธไปยังโมดูล เช่น NODE_ICU_DATA=node_modules/full-icu

ข้อมูลเมตา HTML

มีสามส่วนในแท็ก HTML และส่วนหัวที่ควรอัปเดตด้วยการแปลแต่ละครั้ง:

• ภาษาของเพจ
• ทิศทางการเขียน
• ภาษาอื่นที่หน้ามีอยู่ใน

องค์ประกอบแรกในองค์ประกอบ html ที่มีคุณสมบัติ dir และ lang ตามลำดับ เช่น <html lang="en" dir-"ltr"> สำหรับภาษาอังกฤษแบบสหรัฐอเมริกา การตั้งค่าเหล่านี้อย่างเหมาะสมจะช่วยให้มั่นใจได้ว่าเนื้อหาจะไหลไปในทิศทางที่ถูกต้อง และสามารถช่วยให้เบราว์เซอร์เข้าใจว่าหน้าเว็บนั้นเป็นภาษาใด ทำให้มีคุณลักษณะเพิ่มเติม เช่น การแปลเนื้อหา นอกจากนี้ คุณควรรวมลิงก์ rel="alternate" เพื่อให้เครื่องมือค้นหาทราบว่าหน้าได้รับการแปลอย่างสมบูรณ์แล้ว ดังนั้นการรวม <link href="/es" rel="alternate" hreflang="es"> ในหน้า Landing Page ภาษาอังกฤษของเราจะ ให้เครื่องมือค้นหาทราบว่ามีการแปลที่ควรจับตามอง

การออกแบบภายใน

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

มีหน่วย CSS จำนวนมากที่ออกแบบมาเพื่อทำงานกับเนื้อหาโดยเฉพาะ มีหน่วย em และ rem ที่แสดงขนาดแบบอักษรที่คำนวณและขนาดแบบอักษรของรูทตามลำดับ การสลับค่า px ขนาดคงที่สำหรับหน่วยเหล่านี้สามารถช่วยให้ไซต์ตอบสนองต่อเนื้อหาได้ดีขึ้น จากนั้นจะมีหน่วย ch ซึ่งแสดงขนาดอินไลน์ของสัญลักษณ์ 0 (ศูนย์) ในแบบอักษร วิธีนี้ทำให้คุณสามารถผูกสิ่งต่างๆ เช่น width เข้ากับเนื้อหาที่มีอยู่ได้โดยตรง

หน่วยเหล่านี้สามารถรวมกับเครื่องมือ CSS ที่มีอยู่และทรงพลังสำหรับเลย์เอาต์ โดยเฉพาะ flexbox และ grid กับส่วนประกอบที่ปรับให้เข้ากับขนาด และเลย์เอาต์จะปรับให้เข้ากับเนื้อหา การปรับปรุงคุณสมบัติทางลอจิคัลสำหรับเส้นขอบ ระยะขอบ และช่องว่างภายในแทนคุณสมบัติทางกายภาพจริง ทำให้เลย์เอาต์และส่วนประกอบเหล่านั้นปรับให้เข้ากับโหมดการเขียนโดยอัตโนมัติเช่นกัน พลังของการออกแบบเว็บที่แท้จริง (สร้างโดย Jen Simmons หน่วยที่รับรู้เนื้อหา และคุณสมบัติเชิงตรรกะช่วยให้สามารถออกแบบและสร้างอินเทอร์เฟซเพื่อให้สามารถปรับให้เข้ากับภาษาใดก็ได้ ไม่ใช่แค่ขนาดหน้าจอใดๆ

โลคัลไลเซชัน (l10n)

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

กลยุทธ์เนื้อหา

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

กลยุทธ์เนื้อหามีคำจำกัดความมากมาย แต่ในที่นี้หมายถึงโครงสร้างของเนื้อหา ไมโครสำเนา (คำและวลีที่ใช้ในโปรเจ็กต์ที่ไม่ผูกติดอยู่กับเนื้อหาเฉพาะ) และความเชื่อมโยงของเนื้อหา สำหรับข้อมูลโดยละเอียดเพิ่มเติมเกี่ยวกับกลยุทธ์เนื้อหา ฉันขอแนะนำ Content Strategy for Mobile โดย Karen McGrane และ Designing Connected Content โดย Carrie Hane และ Mike Atherton

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

โมเดลเนื้อหาครอบคลุมเฉพาะบางส่วนของสิ่งที่ต้องแปลเท่านั้น ที่เหลือ—ปุ่ม “อ่านเพิ่มเติม”, ชื่อ “เมนู”, ข้อความปฏิเสธความรับผิดชอบ—นั่นคือไมโครสำเนาทั้งหมด กล้องจุลทรรศน์ต้องการโครงสร้างด้วย แม้ว่าโมเดลเนื้อหาอาจดูเป็นธรรมชาติในการสร้าง โดยเฉพาะสำหรับไซต์ที่ขับเคลื่อนด้วยเทมเพลต แต่โมเดลไมโครคัดลอกมักจะมีความชัดเจนน้อยกว่าและมักถูกมองข้ามโดยไม่ได้ตั้งใจโดยการเขียนสิ่งที่จำเป็นลงในเทมเพลตโดยตรง

โดยการสร้างเนื้อหาและแบบจำลองไมโครโคปและการบังคับใช้—ผ่านระบบการจัดการเนื้อหา การวางซ้อน หรือการตรวจทาน—คุณสามารถมั่นใจได้ว่าการปรับให้เข้ากับท้องถิ่นสามารถมุ่งเน้นไปที่การโลคัลไลซ์เซชั่น

โลคัลไลซ์ค่า ไม่ใช่คีย์

โมเดลเนื้อหาและไมโครสำเนามักจะสร้างโครงสร้างที่คล้ายกับอ็อบเจ็กต์ในโค้ดเบส ไม่ว่าจะเป็นรายการฐานข้อมูล ออบเจ็กต์ JSON YAML หรือ Front Matter อย่าแปลคีย์วัตถุ! หากคุณมี microcopy ข้อความค้นหาอยู่ในวัตถุ microcopy ที่ microcopy.search.text อย่าวางไว้ในวัตถุ microcopie ที่ microcopie.chercher.texte คีย์ในโมดูลควรถือเป็นตัวระบุการโลคัลไลเซชัน-ไม่เชื่อเรื่องพระเจ้า เพื่อให้สามารถใช้คีย์เหล่านี้ได้อย่างน่าเชื่อถือในเทมเพลตที่นำกลับมาใช้ใหม่ได้และเชื่อถือได้ตลอดทั้งโค้ดเบส นอกจากนี้ยังหมายความว่าไม่ควรแสดงคีย์อ็อบเจ็กต์แก่ผู้ใช้ปลายทางเป็นเนื้อหาหรือไมโครสำเนา

การตั้งค่าไซต์แบบคงที่

สำหรับ chromeOS.dev เราใช้ Eleventy (11ty) กับ Nunjucks เป็นตัวสร้างไซต์แบบสแตติกของเรา แต่คำแนะนำเหล่านี้สำหรับการตั้งค่าตัวสร้างไซต์แบบสแตติกควรใช้ได้กับตัวสร้างไซต์แบบสแตติกส่วนใหญ่ เมื่อมีบางสิ่งที่เฉพาะเจาะจง 11ty ก็จะถูกเรียกออกมา

โครงสร้างโฟลเดอร์

ตัวสร้างไซต์แบบคงที่ที่คอมไพล์ตามโครงสร้างโฟลเดอร์นั้นดีเป็นพิเศษในการสนับสนุนเมธอด subdirectory i18n 11ty ยังสนับสนุน data cascade ที่มีข้อมูลส่วนกลางและวิธีการสร้างเพจจากข้อมูลผ่านการแบ่งหน้า ดังนั้นการรวมแนวคิดทั้งสามนี้จะทำให้ได้โครงสร้างโฟลเดอร์พื้นฐานที่มีลักษณะดังนี้:

 . └── pages ├── _data ├── _generated └── {{locale-code}} ├── {{locale-code}}.11tydata.js ├── _data └── [...content]

ที่ระดับบนสุด มีไดเร็กทอรีสำหรับเก็บเพจสำหรับไซต์ ซึ่งเรียกว่า pages ภายในมีโฟลเดอร์ _data ที่มีไฟล์ข้อมูลส่วนกลาง โฟลเดอร์นี้มีความสำคัญเมื่อพูดถึงผู้ช่วยต่อไป จากนั้นจะมีโฟลเดอร์ _generated เรามีหน้าเว็บจำนวนหนึ่งที่สร้างขึ้นจากเนื้อหาที่มีอยู่ ไมโครสำเนาจำนวนเล็กน้อย หรือทั้งสองอย่างรวมกัน แทนที่จะมีเนื้อหาเป็นของตัวเอง คิดว่าหน้าแรก หน้าค้นหา หรือหน้า Landing Page ของส่วนบล็อก เนื่องจากหน้าเหล่านี้มีเทมเพลตสูง เราจึงเก็บเทมเพลตไว้ในโฟลเดอร์ _generated และสร้างจากที่นั่น แทนที่จะมีไฟล์ HTML หรือ Markdown แต่ละไฟล์สำหรับแต่ละไฟล์ โฟลเดอร์เหล่านี้นำหน้าด้วยขีดล่างเพื่อระบุว่าไม่ได้ส่งออกหน้าโดยตรงข้างใต้ แต่ใช้เพื่อสร้างหน้าที่อื่น

ถัดไป ไดเรกทอรีย่อย l10n! แต่ละไดเร็กทอรีควรตั้งชื่อตามแท็กภาษา BCP47 (โดยทั่วไปแล้วคือโค้ดโลแคล) สำหรับการแปลในไดเร็กทอรีนั้น: ตัวอย่างเช่น en สำหรับภาษาอังกฤษ หรือ en-US สำหรับภาษาอังกฤษแบบอเมริกัน ในฐานรหัส chromeOS.dev เรามักจะเรียกสิ่งเหล่านี้ว่า locales เช่นกัน โฟลเดอร์เหล่านี้จะกลายเป็นไดเร็กทอรีย่อยการโลคัลไลเซชัน โดยแบ่งส่วนเนื้อหาเป็นโลคัลไลเซชัน data cascade ของ 11ty ช่วยให้ข้อมูลสามารถใช้ได้กับทุกไฟล์ในไดเร็กทอรีและรายการย่อยหากไฟล์อยู่ที่รูทของไดเร็กทอรีและตั้งชื่อเหมือนกับไดเร็กทอรี (เรียกว่าไฟล์ข้อมูลไดเร็กทอรี) 11ty ใช้อ็อบเจ็กต์ที่ส่งคืนจากไฟล์นี้ หรือฟังก์ชันที่ส่งคืนอ็อบเจ็กต์ และแทรกลงในตัวแปรที่มีให้สำหรับการสร้างเทมเพลต ดังนั้นเราจึงมีสิทธิ์เข้าถึงข้อมูลที่นี่สำหรับเนื้อหาทั้งหมดของการแปลเป็นภาษาท้องถิ่นนั้น

เพื่อช่วยในการบำรุงรักษาไฟล์เหล่านี้ เราได้เขียนตัวช่วยที่เรียกว่า l10n-data ซึ่งเป็นส่วนหนึ่งของโครงสร้างนั่งร้านแบบสแตติกไซต์ของเรา ซึ่งใช้ประโยชน์จากโครงสร้างโฟลเดอร์นี้เพื่อสร้างการเรียงซ้อนของข้อมูลที่แปล ทำให้สามารถแปลข้อมูลได้ทีละน้อย ทำได้โดยเก็บข้อมูลไว้ในไดเร็กทอรีข้อมูลเฉพาะโลแคล ไดเร็กทอรี _data ในนั้น (โหลดลงในไฟล์ข้อมูลไดเร็กทอรี) ตัวอย่างเช่น หากคุณดูในไดเร็กทอรีข้อมูลสถานที่ภาษาอังกฤษ คุณจะเห็นโมเดลไมโครโค้ด เช่น locale.json ซึ่งกำหนดรหัสภาษาและทิศทางการเขียนที่จะแสดงเป็น HTML, newsletter.yml ซึ่งกำหนดไมโครสำเนาที่จำเป็นสำหรับเรา การสมัครรับจดหมายข่าว และไฟล์ microcopy.yml ที่มี microcopy ทั่วไปที่ใช้ในไซต์ต่างๆ หลายแห่ง ซึ่งไม่เหมาะกับไฟล์ที่เฉพาะเจาะจงมากขึ้น ทุกที่ที่มีการใช้ไมโครสำเนานี้ เราจะดึงข้อมูลจากข้อมูลนี้ผ่านการเพิ่มตัวแปรข้อมูล 11 ตัวลงในเทมเพลตของเราเพื่อใช้งาน

Microcopy มีแนวโน้มที่จะจัดการได้ยากที่สุด ในขณะที่เนื้อหาที่เหลือส่วนใหญ่ตรงไปตรงมา ใส่เนื้อหาของคุณ ซึ่งมักจะเป็นไฟล์ Markdown หรือ HTML ลงในโฟลเดอร์ย่อยที่แปลแล้ว สำหรับตัวสร้างไซต์แบบคงที่ที่ทำงานบนโครงสร้างโฟลเดอร์ ชื่อไฟล์และโครงสร้างโฟลเดอร์ของเนื้อหาโดยทั่วไปจะจับคู่ 1:1 กับ URL สุดท้ายของเนื้อหานั้น ดังนั้นไฟล์ Markdown ที่ en/web/pwas.md จะส่งออกไปยัง URL en/web/pwa . ตามหลักการ "ค่า ไม่ใช่คีย์" ของการแปลเป็นภาษาท้องถิ่น เราตัดสินใจว่าจะไม่แปลชื่อไฟล์เนื้อหา (และด้วยเหตุนี้พาธ) ทำให้ง่ายต่อการติดตามสถานะการแปลไฟล์เดียวกันในทุกภาษาและเพื่อให้ผู้ใช้ทราบ อยู่ในหน้าที่ถูกต้องระหว่างสถานที่ต่างๆ

ผู้ช่วย I18n

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

อย่างแรกคือตัวกรองวันที่ เรากำหนดวันที่ทั้งหมดในเนื้อหาของเราให้เป็นมาตรฐานเป็นค่าวันที่ของ YAML เนื่องจากเราเขียนวันที่เป็นส่วนใหญ่ใน YAML และจะพร้อมใช้งานในเทมเพลตของเราเป็นการประทับเวลา UTC แบบเต็ม เมื่อใช้โมดูล full-icu และการกำหนดค่า สตริงวันที่ (เนื้อหาที่มีการเปลี่ยนแปลง) พร้อมกับโค้ดโลแคลสำหรับเนื้อหาที่กำลังแสดงผล สามารถส่งโดยตรงไปยัง Date.toLocaleString (พร้อมตัวเลือกการจัดรูปแบบที่เป็นตัวเลือก) เพื่อแสดงวันที่ที่แปล คุณสามารถใช้ Date.toLocaleDateString แทนได้ ถ้าคุณต้องการเพียงแค่ส่วนวันที่เมื่อไม่มีตัวเลือกการจัดรูปแบบถูกส่ง แทนที่จะเป็นวันที่และเวลาที่แปลแบบเต็ม

ตัวกรองที่สองคือสิ่งที่เราเรียกว่า localURL การดำเนินการนี้ใช้ URL ในเครื่อง (เนื้อหากำลังถูกเปลี่ยนแปลง) และตำแหน่งที่ URL ควรอยู่ และสลับไปมา มันเปลี่ยนตัวอย่างเช่น /en/linux เป็น /es/linux

ตัวกรองสองตัวสุดท้ายเกี่ยวกับการดึงข้อมูลที่แปลเป็นภาษาท้องถิ่นจากโค้ดสถานที่เพียงอย่างเดียว ส่วนที่สามใช้ประโยชน์จากโมดูล iso-639-10 เพื่อแปลงรหัสสถานที่เป็นชื่อภาษาในภาษาแม่ เราใช้ตัวเลือกนี้เป็นหลักสำหรับตัวเลือกภาษาของเรา ส่วนที่สี่ใช้โมดูล iso-i18n-countries เพื่อดึงรายชื่อประเทศในภาษานั้น เราใช้เป็นหลักในการสร้างแบบฟอร์มที่มีรายชื่อประเทศ

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

ผู้ช่วยคนสุดท้ายและสำคัญที่สุดของเราคือข้อมูลทั่วโลกของไซต์ โดยอาศัยโครงสร้างไดเรกทอรีย่อยตามรหัสสถานที่ ฟังก์ชันนี้จะกำหนดแบบไดนามิกที่ไซต์สนับสนุน มันสร้างตัวแปรส่วนกลาง site ซึ่งรวมถึงคุณสมบัติ l10n ที่มีเนื้อหาเฉพาะของ microcopy และการแปลเป็นภาษาท้องถิ่นจาก {{locale-code}}.11tydata.js นอกจากนี้ยังมีคุณสมบัติ languages ที่แสดงรายการสถานที่ที่มีอยู่ทั้งหมดเป็นอาร์เรย์ สุดท้ายนี้ ฟังก์ชันจะแสดงผลไฟล์ JavaScript โดยให้รายละเอียดว่าเว็บไซต์รองรับภาษาใดบ้างและไฟล์แต่ละรายการสำหรับแต่ละรายการใน {{locale-code}}.11tydata.js ที่ใส่คีย์ต่อการแปลเป็นภาษาท้องถิ่น ทั้งหมดนี้ออกแบบมาเพื่อนำเข้าโดยสคริปต์เบราว์เซอร์ของเรา การทำงานหนักของไฟล์นี้เชื่อมโยงไซต์แบบสแตติกของเรากับ JavaScript ส่วนหน้า โดยแหล่งข้อมูลเดียวคือข้อมูลการแปลเป็นภาษาท้องถิ่นที่เราต้องการอยู่แล้ว นอกจากนี้ยังช่วยให้เราสร้างหน้าเว็บโดยทางโปรแกรมตามการแปลของเราได้โดยการวนซ้ำ site.l10n เมื่อรวมกับคอลเล็กชันเฉพาะการแปลของเรา ให้เราใช้การแบ่งหน้าของ 11ty เพื่อสร้างหน้าแรกที่แปลแล้วและหน้า Landing Page ของข่าวโดยไม่ต้องดูแลหน้า HTML แยกกันสำหรับแต่ละหน้า

บทสรุป

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