Internasionalisasi Dan Lokalisasi Untuk Situs Statis

Internasionalisasi dan pelokalan lebih dari sekadar menulis konten Anda dalam berbagai bahasa. Anda memerlukan strategi untuk menentukan lokalisasi apa yang akan dikirim, dan kode untuk melakukannya. Anda harus dapat mendukung tidak hanya bahasa yang berbeda, tetapi juga wilayah yang berbeda dengan bahasa yang sama. UI Anda harus responsif, tidak hanya untuk ukuran layar, tetapi juga untuk berbagai bahasa dan mode penulisan. Konten Anda perlu terstruktur, hingga mikrokopi di UI Anda dan format tanggal Anda, agar dapat disesuaikan dengan bahasa apa pun yang Anda gunakan. Melakukan semua ini dengan generator situs statis, seperti Eleventy, dapat membuatnya lebih sulit, karena Anda mungkin tidak memiliki database, tetapi server. Itu semua bisa dilakukan, tapi butuh perencanaan.

Saat membangun chromeOS.dev, kami tahu bahwa kami perlu membuatnya tersedia untuk audiens global. Memastikan bahwa basis kode kami dapat mendukung banyak lokal (bahasa, wilayah, atau kombinasi keduanya) tanpa perlu membuat kode khusus masing-masing, sementara memungkinkan terjemahan dilakukan dengan sesedikit mungkin pengetahuan sistem itu, akan sangat penting untuk membuat ini terjadi. Pembuat konten kami harus dapat fokus pada pembuatan konten, dan penerjemah kami pada menerjemahkan konten, dengan pekerjaan sesedikit mungkin untuk memasukkan pekerjaan mereka ke dalam situs dan diterapkan. Menyelesaikan serangkaian kebutuhan yang terkadang saling bertentangan ini adalah inti dari apa yang diperlukan untuk menginternasionalkan basis kode dan melokalisasi situs.

Internasionalisasi (i18n) dan lokalisasi (l10n) adalah dua sisi mata uang yang sama. Internasionalisasi adalah tentang bagaimana, dalam kasus kami, perangkat lunak, dirancang sehingga dapat disesuaikan untuk berbagai bahasa dan wilayah tanpa memerlukan perubahan teknik. Lokalisasi, di sisi lain, adalah tentang mengadaptasi perangkat lunak untuk bahasa dan wilayah tersebut. Internasionalisasi dapat terjadi di seluruh tumpukan situs web; dari HTML, CSS, dan JS untuk merancang pertimbangan dan membangun sistem. Lokalisasi terjadi sebagian besar dalam pembuatan konten (baik salinan bentuk panjang maupun mikrokopi) dan manajemen.

Catatan : Bagi yang penasaran, i18n dan l10n adalah jenis singkatan yang dikenal sebagai numeronyms. A11y, untuk aksesibilitas, adalah numeronym umum lainnya dalam pengembangan web.

Internasionalisasi (i18n)

Saat mencari tahu tentang internasionalisasi, umumnya ada tiga item yang perlu Anda pertimbangkan: cara mengetahui bahasa dan/atau wilayah apa yang diinginkan pengguna, cara memastikan mereka mendapatkan konten dalam pelokalan pilihan mereka, dan cara menyesuaikan situs Anda untuk menyesuaikan diri. perbedaan-perbedaan itu. Meskipun implementasi spesifik dapat berubah untuk situs dinamis (yang merender halaman saat pengguna memintanya) dan situs statis (tempat halaman dibuat sebelum disebarkan), konsep inti harus tetap sama.

Menentukan Bahasa dan Wilayah Pengguna

Hal pertama yang perlu dipertimbangkan ketika mencari tahu internasionalisasi adalah menentukan bagaimana Anda ingin pengguna mengakses konten yang dilokalkan. Keputusan ini akan menjadi dasar bagaimana Anda menyiapkan sistem lain, jadi penting untuk memutuskan ini lebih awal dan memastikan bahwa pengorbanannya bekerja dengan baik untuk pengguna Anda.

Secara umum, ada tiga cara tingkat tinggi untuk menentukan pelokalan yang akan ditayangkan kepada pengguna:

1. Lokasi dari alamat IP;
2. Header Accept-Language atau navigator.languages ​​;
3. Pengidentifikasi di URL.

Banyak sistem akhirnya menggabungkan satu, dua, atau ketiganya, ketika memutuskan lokalisasi apa yang akan dilayani. Namun, saat kami menyelidikinya, kami menemukan masalah dengan penggunaan alamat IP dan header Accept-Language yang menurut kami cukup signifikan untuk dihapus dari pertimbangan bagi kami:

• Bahasa pilihan pengguna sering kali tidak berkorelasi dengan lokasi fisik mereka, yang disediakan oleh alamat IP. Hanya karena seseorang secara fisik berada di Amerika, misalnya, tidak berarti bahwa mereka lebih menyukai konten bahasa Inggris.
• Analisis lokasi dari alamat IP sulit, umumnya tidak dapat diandalkan, dan dapat mencegah situs dirayapi oleh mesin telusur.
• Header Accept-Language seringkali tidak pernah diatur secara eksplisit, dan hanya memberikan informasi tentang bahasa, bukan wilayah. Karena keterbatasannya, ini mungkin berguna untuk membuat dugaan awal tentang bahasa, tetapi tidak selalu dapat diandalkan.

Untuk alasan ini, kami memutuskan bahwa akan lebih baik bagi kami untuk tidak mencoba dan menyimpulkan bahasa atau wilayah sebelum pengguna membuka situs kami, tetapi memiliki indikator yang kuat di URL kami. Memiliki indikator yang kuat juga memungkinkan kami untuk berasumsi bahwa mereka mendapatkan situs dalam bahasa yang mereka inginkan dari URL akses mereka saja, menyediakan cara mudah untuk berbagi konten yang dilokalkan secara langsung tanpa memperhatikan pengalihan, dan menyediakan cara yang bersih bagi kami untuk membiarkan pengguna mengganti bahasa pilihan mereka.

Ada tiga pola umum untuk membangun pengidentifikasi ke dalam URL:

1. Berikan domain yang berbeda (biasanya TLD atau subdomain untuk wilayah dan bahasa yang berbeda (misalnya example.com dan example.de , en.example.org dan de.example.org );
2. Memiliki sub-direktori lokal untuk konten (misalnya example.com/en dan example.com/de );
3. Sajikan konten yang dilokalkan berdasarkan parameter URL (misalnya example.com?loc=en dan example.com?loc=de ).

Meskipun umum digunakan, parameter URL umumnya tidak disarankan karena sulit bagi pengguna untuk mengenali pelokalan (bersama dengan sejumlah masalah analitik dan pengelolaan). Kami juga memutuskan bahwa domain yang berbeda bukanlah solusi yang baik bagi kami; situs kami adalah Aplikasi Web Progresif dan setiap domain, termasuk TLD dan subdomain, dianggap sebagai asal yang berbeda, yang secara efektif memerlukan PWA terpisah untuk setiap pelokalan.

Kami memutuskan untuk menggunakan subdirektori, yang memberikan bonus kami dapat melokalkan hanya pada bahasa ( example.com/en ) atau bahasa dan wilayah ( example.com/en-US dan example.com/en-GB ) sesuai kebutuhan saat mempertahankan satu PWA. Kami juga memutuskan bahwa setiap pelokalan situs kami akan berada dalam subdirektori sehingga satu bahasa tidak ditinggikan di atas yang lain, dan bahwa semua URL, kecuali untuk subdirektori, akan identik di seluruh pelokalan berdasarkan bahasa pembuat, memungkinkan pengguna untuk dengan mudah mengubah pelokalan tanpa perlu menerjemahkan URL.

Melayani Konten Lokal

Setelah strategi untuk menentukan bahasa dan wilayah pengguna ditentukan, Anda memerlukan cara untuk menyajikan konten yang tepat secara andal kepada mereka. Setidaknya, ini akan memerlukan beberapa bentuk informasi yang disimpan, baik itu dalam cookie, beberapa penyimpanan lokal, atau bagian dari logika kustom aplikasi Anda. Mampu menjaga preferensi lokalisasi pengguna adalah bagian penting dari pengalaman pengguna i18n; jika pengguna telah mengidentifikasi bahwa mereka menginginkan konten dalam bahasa Jerman, dan mereka mendarat di konten bahasa Inggris, Anda harus dapat mengidentifikasi bahasa pilihan mereka dan mengarahkan mereka dengan tepat. Ini dapat dilakukan di server, tetapi solusi yang kami gunakan untuk chromeOS.dev adalah hosting dan penyiapan server agnostik: kami menggunakan pekerja layanan. Perjalanan pengguna adalah sebagai berikut:

• Seorang pengguna datang ke situs kami untuk pertama kalinya. Pekerja layanan kami tidak diinstal.
• Lokalisasi apa pun yang mereka gunakan, kami tetapkan sebagai bahasa pilihan mereka di IndexedDB. Untuk ini, kami menganggap mereka mendarat di sana melalui beberapa cara, baik sosial, rujukan, atau pencarian, yang mengarahkan mereka berdasarkan konteks pelokalan lain yang tidak kami miliki. Jika pengguna mendarat tanpa perangkat pelokalan, kami menyetelnya ke bahasa Inggris, karena itu adalah bahasa utama situs kami. Kami juga memiliki pengalih bahasa di footer kami untuk memungkinkan pengguna mengubah bahasa mereka. Pada titik ini, pekerja layanan kami harus diinstal.
• Setelah service worker dipasang, kami mencegat semua permintaan URL untuk navigasi situs. Karena pelokalan kami berbasis subdirektori, kami dapat dengan mudah mengidentifikasi pelokalan apa yang diminta. Setelah diidentifikasi, kami memeriksa apakah halaman yang diminta berada dalam subdirektori yang dilokalkan, memeriksa apakah subdirektori yang dilokalkan ada dalam daftar pelokalan yang didukung, dan memeriksa apakah subdirektori yang dilokalkan cocok dengan preferensi mereka yang disimpan di IndexedDB. Jika tidak ada dalam subdirektori yang dilokalkan atau subdirektori yang dilokalkan cocok dengan preferensi mereka, kami akan menayangkan laman tersebut; jika tidak, kami melakukan pengalihan 302 dari pekerja layanan kami untuk pelokalan yang tepat.

Kami menggabungkan solusi kami ke dalam plugin Kotak Kerja, Pengalihan Internasionalisasi Pekerja Layanan. Plugin, bersama dengan sub-modul preferensinya, dapat digabungkan untuk mengatur dan mendapatkan preferensi bahasa pengguna dan mengelola pengalihan ketika dikombinasikan dengan metode registerRoute Workbox dan memfilter permintaan pada request.mode === 'navigate' .

Contoh lengkap dan minimal terlihat seperti ini:

Kode Klien

 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 } });

Kode Pekerja Layanan

 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), );

Dengan kombinasi kode sisi klien dan pekerja layanan, pelokalan pilihan pengguna akan secara otomatis disetel saat mereka membuka situs untuk pertama kali dan, jika mereka menavigasi ke URL yang tidak ada di pelokalan pilihan mereka, mereka akan dialihkan.

Mengadaptasi Antarmuka Pengguna Situs

Ada banyak hal yang perlu dilakukan untuk mengadaptasi antarmuka pengguna dengan benar, jadi meskipun tidak semuanya akan dibahas di sini, ada beberapa hal yang lebih halus yang dapat dan harus dikelola secara terprogram.

Kutipan Blockquote

Pola desain yang umum adalah memiliki blockquotes yang dibungkus dengan tanda kutip, tetapi tahukah Anda apa yang digunakan untuk tanda kutip tersebut bervariasi dengan pelokalan? Alih-alih hard-coding, gunakan open-quote close-quote untuk memastikan kutipan yang benar digunakan untuk bahasa yang benar.

Format Tanggal Dan Angka

Baik tanggal dan angka memiliki metode, .toLocaleString untuk memungkinkan pemformatan berdasarkan lokalisasi (bahasa dan/atau wilayah). Peramban yang mendukung ini dikirimkan dengan semua pelokalan yang tersedia, membuatnya siap digunakan di sana, tetapi Node.js tidak. Untungnya, modul full-icu untuk Node memungkinkan Anda untuk menggunakan semua data lokalisasi yang tersedia. Untuk melakukannya, setelah menginstal modul, jalankan kode Anda dengan variabel lingkungan NODE_ICU_DATA yang disetel ke jalur ke modul, misalnya NODE_ICU_DATA=node_modules/full-icu .

Informasi Meta HTML

Ada tiga area di tag dan header HTML Anda yang harus diperbarui dengan setiap pelokalan:

• Bahasa halaman,
• arah penulisan,
• Bahasa alternatif halaman tersedia.

Yang pertama menggunakan elemen html dengan properti dir dan lang masing-masing, misalnya <html lang="en" dir-"ltr"> untuk bahasa Inggris AS. Menyetelnya dengan benar akan memastikan konten mengalir ke arah yang benar dan memungkinkan browser memahami bahasa apa halaman tersebut, memungkinkan fitur tambahan seperti menerjemahkan konten. Anda juga harus menyertakan tautan rel="alternate" untuk memberi tahu mesin telusur bahwa halaman telah diterjemahkan sepenuhnya, jadi menyertakan <link href="/es" rel="alternate" hreflang="es"> di halaman arahan bahasa Inggris kami akan biarkan mesin pencari tahu bahwa ini memiliki terjemahan yang harus diwaspadai.

Desain Intrinsik

Melokalkan konten dapat menghadirkan tantangan desain karena terjemahan yang berbeda akan memakan banyak ruang di halaman. Beberapa bahasa, seperti Jerman, memiliki kata-kata yang lebih panjang yang membutuhkan lebih banyak ruang horizontal atau pembungkusan teks yang lebih memaafkan. Bahasa lain, seperti bahasa Arab, memiliki tipografi yang lebih tinggi yang membutuhkan lebih banyak ruang vertikal. Untungnya, ada sejumlah alat CSS untuk membuat spasi dan tata letak responsif tidak hanya pada ukuran viewport, tetapi juga konten, yang berarti mereka lebih baik beradaptasi dengan berbagai bahasa.

Ada sejumlah unit CSS yang dirancang khusus untuk bekerja dengan konten. Ada unit em dan rem yang masing-masing mewakili ukuran font yang dihitung dan ukuran font root. Mengganti nilai px ukuran tetap untuk unit ini bisa sangat membantu dalam membuat situs lebih responsif terhadap kontennya. Lalu ada unit ch , yang mewakili ukuran inline dari mesin terbang 0 (nol) dalam font. Ini memungkinkan Anda untuk mengikat hal-hal seperti width , misalnya, langsung ke konten yang dikandungnya.

Unit-unit ini kemudian dapat digabungkan dengan alat CSS yang sudah ada dan canggih untuk tata letak, khususnya flexbox dan kisi, ke komponen yang beradaptasi dengan ukurannya, dan tata letak yang beradaptasi dengan kontennya. Meningkatkan mereka dengan properti logis untuk batas, margin, dan padding alih-alih properti fisik fisik membuat tata letak dan komponen tersebut secara otomatis beradaptasi dengan mode penulisan juga. Kekuatan desain web intrinsik (diciptakan oleh Jen Simmons, unit sadar konten, dan properti logis memungkinkan antarmuka dirancang dan dibangun sehingga dapat beradaptasi dengan bahasa apa pun, bukan sembarang ukuran layar.

Lokalisasi (l10n)

Bentuk pelokalan yang paling jelas adalah menerjemahkan konten dari satu bahasa ke bahasa lain. Dalam bentuk yang lebih halus, terjemahan tidak hanya terjadi berdasarkan bahasa, tetapi wilayah yang digunakan, misalnya, bahasa Inggris yang diucapkan di Amerika versus bahasa Inggris yang digunakan di Inggris, Afrika Selatan, atau Australia. Agar sukses di sini, memahami apa yang harus diterjemahkan dan bagaimana menyusun konten Anda untuk terjemahan sangat penting untuk kesuksesan.

Strategi Konten

Ada beberapa bagian dari proyek perangkat lunak yang penting untuk dilokalkan, dan ada juga yang tidak. Nama kelas CSS, variabel JavaScript, dan tempat lain di basis kode Anda yang bersifat struktural, tetapi tidak menghadap pengguna, mungkin tidak perlu dilokalkan. Mencari tahu apa yang perlu dilokalkan, dan bagaimana menyusunnya, bermuara pada strategi konten.

Strategi konten memiliki banyak definisi, tetapi di sini artinya struktur konten, mikrokopi (kata-kata dan frasa yang digunakan di seluruh proyek yang tidak terikat pada bagian konten tertentu), dan hubungannya. Untuk informasi lebih rinci tentang strategi konten, saya akan merekomendasikan Strategi Konten untuk Seluler oleh Karen McGrane dan Merancang Konten yang Terhubung oleh Carrie Hane dan Mike Atherton.

Untuk chromeOS.dev, kami menyelesaikan kodifikasi model konten yang menjelaskan struktur konten kami. Model konten tidak hanya untuk konten seperti artikel berbentuk panjang; model konten harus ada untuk entitas apa pun yang mungkin diinginkan pengguna secara khusus dari Anda, seperti penulis, dokumen, atau bahkan aset media yang dapat digunakan kembali. Model konten yang baik mencakup potongan yang dapat dialamatkan secara individual, atau potongan, dari potongan konseptual yang lebih besar, sementara mengecualikan potongan yang terkait secara tangensial atau dapat direferensikan dari model konten lain. Misalnya, model konten untuk entri blog dapat menyertakan judul, larik tag, referensi ke penulis, tanggal diterbitkan, dan badan entri, tetapi tidak boleh menyertakan string untuk remah roti, atau nama penulis dan gambar, yang harus menjadi model kontennya sendiri. Model konten tidak berubah dari pelokalan ke pelokalan; mereka adalah struktur situs. Sebuah instance dari model konten terkait dengan pelokalan, dan instance tersebut dapat dilokalkan.

Model konten hanya mencakup sebagian dari apa yang perlu dilokalkan. Selebihnya—tombol “Baca Selengkapnya” Anda, judul “Menu” Anda, teks penafian Anda—itu semua adalah mikrokopi. Mikrokopi juga membutuhkan struktur. Sementara model konten mungkin terasa alami untuk dibuat, terutama untuk situs berbasis template, model mikrokopi cenderung kurang jelas dan sering diabaikan secara tidak sengaja dengan menulis apa yang dibutuhkan langsung di template.

Dengan membangun konten dan model mikrokopi serta menerapkannya—melalui sistem pengelolaan konten, linting, atau peninjauan—Anda dapat memastikan bahwa pelokalan dapat berfokus pada pelokalan.

Lokalkan Nilai, Bukan Kunci

Model konten dan mikrokopi biasanya menghasilkan struktur yang mirip dengan objek dalam basis kode; baik itu entri database, objek JSON, YAML, atau Front Matter. Jangan lokalkan kunci objek! Jika Anda memiliki mikrokopi teks Penelusuran yang terletak di objek microcopy.search.text microcopy jangan letakkan di objek microcopie.chercher.texte microcopie Kunci dalam modul harus diperlakukan sebagai pengidentifikasi agnostik pelokalan sehingga dapat digunakan dengan andal dalam templat yang dapat digunakan kembali dan diandalkan di seluruh basis kode. Ini juga berarti bahwa kunci objek tidak boleh ditampilkan kepada pengguna akhir sebagai konten atau salinan.

Pengaturan Situs Statis

Untuk chromeOS.dev, kami menggunakan Eleventy (11ty) dengan Nunjucks sebagai generator situs statis kami, tetapi rekomendasi untuk menyiapkan generator situs statis ini harus berlaku untuk sebagian besar generator situs statis. Di mana ada sesuatu yang spesifik, itu akan dipanggil.

Struktur Folder

Generator situs statis yang dikompilasi berdasarkan struktur folder sangat baik dalam mendukung metode subdirektori i18n. 11ty juga mendukung kaskade data dengan data global dan sarana untuk menghasilkan halaman dari data melalui pagination, jadi menggabungkan ketiga konsep ini menghasilkan struktur folder dasar yang terlihat seperti berikut:

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

Di tingkat atas, ada direktori untuk menampung halaman situs, di sini disebut pages . Bersarang di dalam, ada folder _data yang berisi file data global. Folder ini penting ketika berbicara tentang pembantu selanjutnya. Lalu, ada folder _generated . Kami memiliki sejumlah halaman yang, alih-alih memiliki konten sendiri, dihasilkan dari konten yang ada, sejumlah kecil salinan, atau kombinasi keduanya. Pikirkan beranda halaman rumah, halaman pencarian, atau halaman arahan bagian blog. Karena halaman ini sangat bertemplat, kami menyimpan templat di folder _generated dan membangunnya dari sana alih-alih memiliki file HTML atau Markdown individual untuk masing-masing halaman. Folder ini diawali dengan garis bawah untuk menunjukkan bahwa folder tersebut tidak menampilkan halaman langsung di bawahnya, melainkan digunakan untuk membuat halaman di tempat lain.

Selanjutnya, l10n subdirektori! Setiap direktori harus diberi nama untuk tag bahasa BCP47 (lebih umum, kode lokal) untuk lokalisasi yang dikandungnya: misalnya, en untuk bahasa Inggris, atau en-US untuk bahasa Inggris Amerika. Dalam basis kode chromeOS.dev, kami juga sering menyebutnya sebagai locales . Folder ini akan menjadi subdirektori pelokalan, mengelompokkan konten ke pelokalan. Kaskade data 11ty memungkinkan data tersedia untuk setiap file dalam direktori dan turunannya jika file tersebut berada di root direktori dan diberi nama yang sama dengan direktori (disebut file data direktori). 11ty menggunakan objek yang dikembalikan dari file ini, atau fungsi yang mengembalikan objek, dan memasukkannya ke dalam variabel yang tersedia untuk templating, jadi kami memiliki akses ke data di sini untuk semua konten pelokalan itu.

Untuk membantu dalam pemeliharaan file-file ini, kami menulis pembantu yang disebut l10n-data , bagian dari perancah situs statis kami, yang memanfaatkan struktur folder ini untuk membangun kaskade data lokal, memungkinkan data dilokalkan sedikit demi sedikit. Ini dilakukan dengan menyimpan data dalam direktori data khusus lokal, direktori _data di dalamnya (dimuat ke dalam file data direktori). Jika Anda melihat di direktori data lokal bahasa Inggris kami, misalnya, Anda akan melihat model mikrokopi seperti locale.json yang mendefinisikan kode bahasa dan arah penulisan yang kemudian akan dirender ke dalam HTML kami, newsletter.yml yang mendefinisikan mikrokopi yang diperlukan untuk kami pendaftaran buletin, dan file microcopy.yml yang menyertakan salinan umum yang digunakan di banyak tempat di seluruh situs yang tidak sesuai dengan file yang lebih spesifik. Di mana pun mikrokopi ini digunakan, kami menariknya dari data yang tersedia melalui 11 puluh variabel data yang disuntikkan ke dalam template kami untuk digunakan.

Mikrokopi cenderung menjadi yang paling sulit untuk dikelola, sedangkan konten lainnya sebagian besar lurus ke depan. Letakkan konten Anda, sering kali file penurunan harga atau HTML, ke dalam subfolder yang dilokalkan. Untuk generator situs statis yang bekerja pada struktur folder, nama file dan struktur folder konten biasanya akan memetakan 1:1 ke URL final untuk konten tersebut, sehingga file penurunan harga di en/web/pwas.md akan ditampilkan ke URL en/web/pwa . Mengikuti prinsip pelokalan “nilai, bukan kunci” kami, kami memutuskan bahwa kami tidak akan melokalkan nama file konten (dan karena itu jalur), sehingga memudahkan kami untuk melacak status pelokalan file yang sama di seluruh lokal dan bagi pengguna untuk mengetahui mereka berada di halaman yang tepat di antara lokal yang berbeda.

Pembantu I18n

Selain konten dan mikrokopi, kami menemukan bahwa kami perlu menulis sejumlah modul pembantu untuk mempermudah pekerjaan dengan konten yang dilokalkan. 11ty memiliki konsep yang disebut filter yang memungkinkan konten dimodifikasi sebelum dirender. Kami akhirnya membangun empat di antaranya untuk membantu templating i18n.

Yang pertama adalah filter tanggal. Kami membuat standar agar semua tanggal di seluruh konten kami ditulis sebagai nilai tanggal YAML karena kami kebanyakan menulisnya dalam YAML dan tersedia di template kami sebagai stempel waktu UTC lengkap. Saat menggunakan modul dan konfigurasi full-icu , string tanggal (konten sedang diubah), bersama dengan kode lokal untuk konten yang sedang dirender, dapat diteruskan langsung ke Date.toLocaleString (dengan opsi pemformatan opsional) untuk merender tanggal yang dilokalkan. Date.toLocaleDateString secara opsional dapat digunakan sebagai gantinya jika Anda hanya ingin bagian tanggal ketika tidak ada opsi pemformatan yang diteruskan, alih-alih tanggal dan waktu terlokalisasi penuh.

Filter kedua adalah sesuatu yang kami sebut localURL . Ini mengambil URL lokal (konten sedang diubah) dan lokal tempat URL seharusnya berada, dan menukarnya. Itu berubah, misalnya, /en/linux menjadi /es/linux .

Dua filter terakhir adalah tentang mengambil informasi lokal dari kode lokal saja. Yang ketiga memanfaatkan modul iso-639-10 untuk mengubah kode lokal menjadi nama bahasa dalam bahasa asli. Ini kami gunakan terutama untuk pemilih bahasa kami. Yang keempat menggunakan modul iso-i18n-countries untuk mengambil daftar negara dalam bahasa tersebut. Ini kami gunakan terutama untuk membuat formulir dengan daftar negara.

Selain filter, 11ty memiliki konsep bernama collections yang merupakan pengelompokan konten. 11ty membuat sejumlah koleksi tersedia secara default, dan bahkan dapat membuat koleksi dari tag. Di situs multibahasa, kami menemukan bahwa kami ingin membuat koleksi khusus. Kami akhirnya membangun sejumlah fungsi pembantu untuk membangun koleksi berdasarkan lokalisasi. Ini memungkinkan kami untuk melakukan hal-hal seperti memiliki kumpulan tag khusus lokasi atau kumpulan bagian situs tanpa perlu memfilter di template kami terhadap semua konten di situs kami.

Pembantu terakhir kami, dan yang paling penting, adalah data global situs kami. Mengandalkan struktur subdirektori berbasis kode lokal, fungsi ini secara dinamis menentukan lokalisasi apa yang didukung situs. Itu membangun variabel global, site , yang mencakup properti l10n , yang berisi semua mikrokopi dan konten khusus pelokalan dari {{locale-code}}.11tydata.js . Ini juga berisi properti languages yang mencantumkan semua lokal yang tersedia sebagai array. Terakhir, fungsi mengeluarkan file JavaScript yang merinci bahasa apa yang didukung oleh situs dan file individual untuk setiap entri dalam {{locale-code}}.11tydata.js , dikunci per lokalisasi, semuanya dirancang untuk diimpor oleh skrip browser kami. Pengangkatan berat file ini mengikat situs statis kami ke JavaScript front-end kami dengan satu-satunya sumber kebenaran adalah informasi pelokalan yang sudah kami butuhkan. Ini juga memungkinkan kami untuk membuat halaman secara terprogram berdasarkan pelokalan kami dengan mengulang site.l10n . Ini, dikombinasikan dengan koleksi khusus pelokalan kami, mari kita gunakan pagination 11ty untuk membuat halaman beranda dan halaman berita yang dilokalkan tanpa memelihara halaman HTML terpisah untuk masing-masing.

Kesimpulan

Mendapatkan internasionalisasi dan lokalisasi yang tepat bisa jadi sulit; memahami bagaimana strategi yang berbeda dan mempengaruhi kompleksitas sangat penting untuk membuatnya lebih mudah. Pilih strategi i18n yang cocok secara alami untuk situs statis, subdirektori, lalu buat alat untuk mengotomatiskan bagian i18n dan i10n dari konten yang sedang diproduksi. Bangun konten yang kuat dan model mikrokopi. Manfaatkan pekerja layanan untuk pelokalan server-agnostik. Ikat semuanya dengan desain yang responsif tidak hanya terhadap ukuran layar, tetapi juga konten. Pada akhirnya Anda akan memiliki situs yang akan disukai oleh pengguna Anda dari semua lokal yang dapat dikelola oleh penulis dan penerjemah seolah-olah itu adalah situs lokal tunggal yang sederhana.