Statik Siteler İçin Uluslararasılaştırma ve Yerelleştirme

Uluslararasılaştırma ve yerelleştirme, içeriğinizi birden çok dilde yazmaktan daha fazlasıdır. Hangi yerelleştirmenin gönderileceğini belirlemek için bir stratejiye ve bunu yapmak için koda ihtiyacınız var. Sadece farklı dilleri değil, aynı dile sahip farklı bölgeleri de destekleyebilmeniz gerekir. Kullanıcı arayüzünüzün yalnızca ekran boyutuna değil, farklı dillere ve yazma modlarına da duyarlı olması gerekir. İçeriğinizin, kullandığınız herhangi bir dile uyarlanabilmesi için kullanıcı arayüzünüzdeki mikro kopyaya ve tarihlerinizin biçimine kadar yapılandırılması gerekir. Tüm bunları Eleventy gibi statik bir site oluşturucu ile yapmak daha da zorlaştırabilir çünkü bir veritabanınız olmasa da bir sunucunuz olabilir. Yine de hepsi yapılabilir, ancak planlama gerektirir.

chromeOS.dev'i oluştururken, onu küresel bir kitleye sunmamız gerektiğini biliyorduk. Kod tabanımızın, her birini özel olarak kodlamaya gerek kalmadan birden fazla yerel ayarı (dil, bölge veya ikisinin birleşimi) destekleyebildiğinden ve çevirinin bu sistem bilgisinin mümkün olduğunca azıyla yapılmasına izin verdiğinden emin olmak, Bu oldu. İçerik oluşturucularımızın içerik oluşturmaya ve çevirmenlerimizin çalışmalarını siteye alıp dağıtmak için mümkün olduğunca az çalışmayla içerik çevirmeye odaklanabilmeleri gerekiyordu. Bu bazen çelişen ihtiyaçları doğru bir şekilde elde etmek, kod tabanlarını uluslararası hale getirmek ve siteleri yerelleştirmek için gerekenlerin kalbidir.

Uluslararasılaştırma (i18n) ve yerelleştirme (l10n) aynı madalyonun iki yüzüdür. Uluslararasılaştırma, bizim durumumuzda yazılımın, mühendislik değişikliklerine ihtiyaç duymadan birden çok dil ve bölgeye uyarlanabilmesi için nasıl tasarlanacağı ile ilgilidir. Yerelleştirme ise yazılımı bu dillere ve bölgelere uyarlamakla ilgilidir. Uluslararasılaştırma, tüm web sitesi yığınında gerçekleşebilir; HTML, CSS ve JS'den önemli noktaları tasarlamaya ve sistemler oluşturmaya kadar. Yerelleştirme, çoğunlukla içerik oluşturma (hem uzun biçimli kopya hem de mikro kopya) ve yönetimde gerçekleşir.

Not : Merak edenler için i18n ve l10n sayısal olarak bilinen kısaltma türleridir. Erişilebilirlik için A11y, web geliştirmede yaygın olarak kullanılan başka bir sayıdır.

Uluslararasılaştırma (i18n)

Uluslararasılaştırmayı belirlerken, genellikle göz önünde bulundurmanız gereken üç öğe vardır: kullanıcının hangi dili ve/veya bölgeyi istediğini nasıl anlayacağınız, içeriği tercih ettikleri yerelleştirmede aldıklarından nasıl emin olacağınız ve sitenizi buna uyum sağlayacak şekilde nasıl uyarlayacağınız. bu farklılıklar. Dinamik siteler (bir kullanıcı istediğinde bir sayfa oluşturan) ve statik siteler (sayfaların dağıtılmadan önce oluşturulduğu yerler) için uygulama özellikleri değişebilse de, temel kavramlar aynı kalmalıdır.

Kullanıcının Dilini ve Bölgesini Belirleme

Uluslararasılaştırmayı belirlerken göz önünde bulundurulması gereken ilk şey, kullanıcıların yerelleştirilmiş içeriğe nasıl erişmesini istediğinizi belirlemektir. Bu karar, diğer sistemleri nasıl kurduğunuz için temel oluşturacaktır, bu nedenle buna erken karar vermek ve ödünlerin kullanıcılarınız için iyi çalışmasını sağlamak önemlidir.

Genel olarak, kullanıcılara hangi yerelleştirmenin sunulacağını belirlemenin üç üst düzey yolu vardır:

1. IP adresinden konum;
2. Accept-Language başlığı veya navigator.languages ;
3. URL'deki tanımlayıcı.

Birçok sistem, hangi yerelleştirmenin hizmet edeceğine karar verirken bir, iki veya üçünü bir araya getirir. Yine de araştırırken, bizim için dikkate alınmaması için yeterince önemli olduğunu düşündüğümüz IP adreslerini ve Accept-Language başlıklarını kullanmayla ilgili sorunlar bulduk:

• Bir kullanıcının tercih ettiği dil, genellikle IP adresinin sağladığı fiziksel konumuyla ilişkili değildir. Örneğin, birinin fiziksel olarak Amerika'da olması, İngilizce içeriği tercih edecekleri anlamına gelmez.
• IP adreslerinden konum analizi zordur, genellikle güvenilmezdir ve sitenin arama motorları tarafından taranmasını engelleyebilir.
• Accept-Language üstbilgileri genellikle hiçbir zaman açıkça ayarlanmaz ve bölge değil, yalnızca dil hakkında bilgi sağlar. Sınırlamaları nedeniyle, bu, dil hakkında bir ilk tahminde bulunmak için yardımcı olabilir, ancak mutlaka güvenilir değildir.

Bu nedenlerden dolayı, bir kullanıcı sitemize girmeden önce dil veya bölge çıkarsamaya çalışmamamız, bunun yerine URL'lerimizde güçlü göstergeler bulundurmamızın daha iyi olacağına karar verdik. Güçlü göstergelere sahip olmak, aynı zamanda, siteyi yalnızca erişim URL'lerinden istedikleri dilde aldıklarını varsaymamızı sağlar, yerelleştirilmiş içeriği yeniden yönlendirme endişesi olmadan doğrudan paylaşmanın kolay bir yolunu sağlar ve izin vermemiz için temiz bir yol sağlar. kullanıcılar tercih ettikleri dili değiştirir.

URL'lerde tanımlayıcı oluşturmaya yönelik üç yaygın model vardır:

1. Farklı alanlar sağlayın (genellikle farklı bölgeler ve diller için TLD'ler veya alt alanlar (örn. example.com ve example.de , en.example.org ve de.example.org );
2. İçerik için yerelleştirilmiş alt dizinlere sahip olun (örn. example.com/en ve example.com/de );
3. URL parametrelerine dayalı olarak yerelleştirilmiş içerik sunun (örn. example.com?loc=en ve example.com?loc=de ).

Yaygın olarak kullanılsa da, kullanıcıların yerelleştirmeyi tanıması zor olduğundan (bir dizi analiz ve yönetim sorunuyla birlikte) URL parametreleri genellikle önerilmez. Ayrıca farklı alan adlarının bizim için iyi bir çözüm olmadığına karar verdik; sitemiz bir Aşamalı Web Uygulamasıdır ve TLD'ler ve alt alanlar dahil olmak üzere her alan, farklı bir kaynak olarak kabul edilir ve etkin bir şekilde her yerelleştirme için ayrı bir PWA gerektirir.

Gerektiğinde yalnızca dilde ( example.com/en ) veya dilde ve bölgede ( example.com/en-US ve example.com/en-GB ) yerelleştirme yapabilmemizi sağlayan alt dizinleri kullanmaya karar verdik. tek bir PWA'nın sürdürülmesi. Ayrıca, sitemizin her yerelleştirmesinin bir alt dizinde yer almasına, böylece bir dilin diğerinin üzerine çıkmamasına ve alt dizin dışındaki tüm URL'lerin, yazma diline dayalı yerelleştirmeler arasında aynı olmasına ve kullanıcıların kolayca değiştirmesine izin vermesine karar verdik. URL'leri çevirmeye gerek kalmadan yerelleştirmeler.

Yerelleştirilmiş İçerik Sunma

Bir kullanıcının dilini ve bölgesini belirlemek için bir strateji belirlendikten sonra, onlara doğru içeriği güvenilir bir şekilde sunmanın bir yoluna ihtiyacınız vardır. En azından bu, bir çerezde, bazı yerel depolamalarda veya uygulamanızın özel mantığının bir parçasında olsun, bir tür depolanmış bilgi gerektirecektir. Bir kullanıcının yerelleştirme tercihlerini tutabilmek, i18n kullanıcı deneyiminin önemli bir parçasıdır; Bir kullanıcı Almanca içerik istediğini belirlediyse ve İngilizce içeriğe ulaştıysa, tercih ettikleri dili belirleyebilmeli ve onları uygun şekilde yönlendirebilmelisiniz. Bu sunucuda yapılabilir, ancak chromeOS.dev için uyguladığımız çözüm barındırma ve sunucu kurulumundan bağımsızdır: hizmet çalışanları kullandık. Kullanıcının yolculuğu şu şekildedir:

• Bir kullanıcı sitemize ilk kez geliyor. Servis çalışanımız kurulu değil.
• Hangi yerelleştirmeye ulaşırlarsa, IndexedDB'de tercih ettikleri dil olarak ayarlıyoruz. Bunun için, bizde olmayan diğer yerelleştirme bağlamlarına dayalı olarak onları yönlendiren sosyal, yönlendirme veya arama gibi bazı yollarla oraya ulaştıklarını varsayıyoruz. Bir kullanıcı yerelleştirme seti olmadan gelirse, sitemizin ana dili olduğu için bunu İngilizce'ye ayarlarız. Ayrıca, bir kullanıcının dilini değiştirmesine izin vermek için alt bilgimizde bir dil değiştiricimiz var. Bu noktada servis çalışanımız kurulmalıdır.
• Servis çalışanı yüklendikten sonra, site gezintisi için tüm URL isteklerini durdururuz. Yerelleştirmelerimiz alt dizine dayalı olduğundan, hangi yerelleştirmenin istendiğini kolayca belirleyebiliriz. Belirlendikten sonra, istenen sayfanın yerelleştirilmiş bir alt dizinde olup olmadığını, yerelleştirilmiş alt dizinin desteklenen yerelleştirmeler listesinde olup olmadığını ve yerelleştirilmiş alt dizinin IndexedDB'de depolanan tercihleriyle eşleşip eşleşmediğini kontrol ederiz. Yerelleştirilmiş bir alt dizinde değilse veya yerelleştirilmiş alt dizin onların tercihleriyle eşleşiyorsa, sayfayı sunarız; aksi takdirde doğru yerelleştirme için servis çalışanımızdan 302 yönlendirmesi yaparız.

Çözümümüzü Workbox eklentisi olan Service Worker Internationalization Redirect içinde paketledik. Eklenti, tercihler alt modülüyle birlikte, bir kullanıcının dil tercihini ayarlamak ve almak ve Workbox'ın registerRoute yöntemi ve request.mode === 'navigate' üzerindeki istekleri filtreleme ile birleştirildiğinde yeniden yönlendirmeyi yönetmek için birleştirilebilir.

Tam, minimal bir örnek şöyle görünür:

Müşteri kodu

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

Servis Çalışanı Kodu

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

İstemci tarafı ve hizmet çalışanı kodunun birleşimiyle, kullanıcıların tercih ettikleri yerelleştirme, siteye ilk geldiklerinde otomatik olarak ayarlanır ve tercih ettikleri yerelleştirmelerde olmayan bir URL'ye giderlerse, yönlendirildi.

Site Kullanıcı Arayüzünü Uyarlama

Kullanıcı arayüzlerini düzgün bir şekilde uyarlamaya giden çok şey var, bu nedenle burada her şey ele alınmayacak olsa da, programlı olarak yönetilebilecek ve yönetilmesi gereken bir avuç daha ince şey var.

Blok Alıntı Alıntılar

Yaygın bir tasarım deseni, tırnak içine alınmış blok alıntılara sahip olmaktır, ancak bu tırnak işaretleri için neyin kullanıldığının yerelleştirmeye göre değiştiğini biliyor muydunuz? Sabit kodlama yerine, doğru dil için doğru alıntıların kullanıldığından emin olmak için open-quote ve close-quote kullanın.

Tarih ve Sayı Formatı

Hem tarih hem de sayıların bir yerelleştirmeye (dil ve/veya bölge) dayalı biçimlendirmeye izin vermek için .toLocaleString adlı bir yöntemi vardır. Bunları destekleyen tarayıcılar, mevcut tüm yerelleştirmelerle birlikte gönderilir, bu da onu orada kolayca kullanılabilir hale getirir, ancak Node.js yapmaz. Neyse ki, Node için tam icu modülü, mevcut tüm yerelleştirme verilerini kullanmanıza izin verir. Bunu yapmak için, modülü kurduktan sonra, kodunuzu NODE_ICU_DATA ortam değişkeni modülün yoluna ayarlanmış olarak çalıştırın, örneğin NODE_ICU_DATA=node_modules/full-icu .

HTML Meta Bilgileri

HTML etiketinizde ve başlıklarınızda her yerelleştirmeyle güncellenmesi gereken üç alan vardır:

• Sayfanın dili,
• Yazı yönü,
• Sayfanın mevcut olduğu alternatif diller.

Sırasıyla dir ve lang özellikleriyle html öğesine ilk giden, örneğin ABD İngilizcesi için <html lang="en" dir-"ltr"> . Bunları uygun şekilde ayarlamak, içeriğin doğru yönde akmasını sağlar ve tarayıcıların, içeriği çevirmek gibi ek özelliklere izin vererek, sayfanın hangi dilde olduğunu anlamalarına olanak tanır. Arama motorlarına bir sayfanın tamamen çevrildiğini bildirmek için rel="alternate" bağlantıları da eklemelisiniz, bu nedenle İngilizce açılış sayfamıza <link href="/es" rel="alternate" hreflang="es"> dahil etmek arama motorlarına bunun aranması gereken bir çevirisi olduğunu bildirin.

İç Tasarım

Farklı çeviriler sayfada farklı miktarda yer kaplayacağından, içeriği yerelleştirmek tasarım zorluklarına neden olabilir. Almanca gibi bazı dillerde, daha fazla yatay boşluk veya daha fazla affedici metin kaydırma gerektiren daha uzun kelimeler vardır. Arapça gibi diğer diller, daha fazla dikey alan gerektiren daha uzun yazı tiplerine sahiptir. Neyse ki, boşlukları ve düzeni yalnızca görüntü alanı boyutuna değil, içeriğe de duyarlı hale getirmek için bir dizi CSS aracı vardır, yani birden çok dile daha iyi uyum sağlarlar.

İçerikle çalışmak için özel olarak tasarlanmış bir dizi CSS birimi vardır. Sırasıyla hesaplanan yazı tipi boyutunu ve kök yazı tipi boyutunu temsil eden em ve rem birimleri vardır. Bu birimler için sabit boyutlu px değerlerinin değiştirilmesi, bir sitenin içeriğine daha duyarlı hale getirilmesinde uzun bir yol kat edebilir. Sonra bir yazı tipindeki 0 (sıfır) glifin satır içi boyutunu temsil eden ch birimi vardır. Bu, örneğin width gibi şeyleri doğrudan içerdiği içeriğe bağlamanıza olanak tanır.

Bu birimler daha sonra mizanpaj için mevcut, güçlü CSS araçlarıyla, özellikle flexbox ve grid ile boyutlarına uyum sağlayan bileşenlere ve mizanpajlar içeriklerine uyum sağlayacak şekilde birleştirilebilir. Fiziksel özellikler yerine kenarlıklar, kenar boşlukları ve dolgu için mantıksal özelliklere sahip olanların geliştirilmesi, bu düzenlerin ve bileşenlerin de otomatik olarak yazma moduna uyum sağlamasını sağlar. İçsel web tasarımının gücü (Jen Simmons tarafından icat edilen, içeriğe duyarlı birimler ve mantıksal özellikler, arayüzlerin tasarlanmasına ve oluşturulmasına olanak tanır, böylece yalnızca herhangi bir ekran boyutuna değil, herhangi bir dile uyarlanabilirler.

Yerelleştirme (l10n)

Yerelleştirmenin aldığı en belirgin biçim, içeriği bir dilden diğerine çevirmektir. Daha ince biçimlerde, çeviriler yalnızca dile göre değil, konuşulan bölgelere göre de gerçekleşir; örneğin, Amerika'da konuşulan İngilizceye karşı Birleşik Krallık, Güney Afrika veya Avustralya'da konuşulan İngilizce. Burada başarılı olmak için neyin çevrileceğini ve içeriğinizi çeviri için nasıl yapılandıracağınızı anlamak başarı için çok önemlidir.

İçerik Stratejisi

Bir yazılım projesinin yerelleştirilmesi önemli olan bazı bölümleri vardır, bazıları da değildir. CSS sınıf adları, JavaScript değişkenleri ve kod tabanınızdaki yapısal olan ancak kullanıcıya yönelik olmayan diğer yerler, muhtemelen yerelleştirilmeleri gerekmez. Neyin yerelleştirilmesi gerektiğini ve nasıl yapılandırılacağını bulmak içerik stratejisine gelir.

İçerik stratejisinin birçok tanımı vardır, ancak burada içeriğin yapısı, mikrokopya (belirli bir içeriğe bağlı olmayan bir proje boyunca kullanılan kelimeler ve deyimler) ve bunların bağlantıları anlamına gelir. İçerik stratejisi hakkında daha ayrıntılı bilgi için, Karen McGrane'in Mobil için İçerik Stratejisi'ni ve Carrie Hane ve Mike Atherton'ın yazdığı Bağlantılı İçerik Tasarlaması'nı öneririm.

chromeOS.dev için, içeriğimizin yapısını tanımlayan içerik modellerini kodlayarak tamamladık. İçerik modelleri yalnızca uzun biçimli makale benzeri içerik için değildir; Bir yazar, belge ve hatta yeniden kullanılabilir medya varlıkları gibi bir kullanıcının sizden özellikle isteyebileceği herhangi bir varlık için bir içerik modeli mevcut olmalıdır. İyi içerik modelleri, ayrı ayrı adreslenebilen parçaları veya daha büyük bir kavramsal parçanın parçalarını içerirken, teğetsel olarak ilişkili veya başka bir içerik modelinden referans alınabilecek parçaları hariç tutar. Örneğin, bir blog gönderisi için bir içerik modeli bir başlık, bir etiket dizisi, bir yazara referans, yayın tarihi ve gönderinin gövdesini içerebilir, ancak içerik kırıntıları dizesini veya kendi içerik modeli olması gereken yazarın adı ve resmi. İçerik modelleri yerelleştirmeden yerelleştirmeye değişmez; onlar site yapısıdır. İçerik modelinin bir örneği bir yerelleştirmeye bağlıdır ve bu örnekler yerelleştirilebilir.

İçerik modelleri, yerelleştirilmesi gerekenlerin yalnızca bir kısmını kapsar. Gerisi—“Daha Fazla Oku” düğmeleriniz, “Menü” başlığınız, sorumluluk reddi metniniz—hepsi bu mikrokopyadır. Mikrokopinin de yapıya ihtiyacı vardır. İçerik modellerinin oluşturulması, özellikle şablona dayalı siteler için doğal görünse de, mikro kopya modelleri daha az belirgin olma eğilimindedir ve genellikle ihtiyaç duyulanı doğrudan bir şablona yazarak yanlışlıkla gözden kaçar.

İçerik ve mikro kopya modelleri oluşturarak ve bunları bir içerik yönetim sistemi, linting veya inceleme yoluyla uygulayarak yerelleştirmenin yerelleştirmeye odaklanabilmesini sağlayabilirsiniz.

Anahtarları Değil, Değerleri Yerelleştirin

İçerik ve mikroskop modelleri genellikle bir kod tabanındaki nesnelere benzer yapılar üretir; veritabanı girişleri, JSON nesnesi, YAML veya Front Matter olsun. Nesne anahtarlarını yerelleştirmeyin! Arama metni mikrokopyanız microcopy.search.text adresindeki bir microcopy nesnesinde bulunuyorsa, onu microcopy.search.text adresindeki bir microcopie nesnesine microcopie.chercher.texte . Modüllerdeki anahtarlar, yeniden kullanılabilir şablonlarda güvenilir bir şekilde kullanılabilmesi ve bir kod temeli boyunca güvenilebilmesi için yerelleştirmeden bağımsız tanımlayıcılar olarak ele alınmalıdır. Bu aynı zamanda nesne anahtarlarının son kullanıcılara içerik veya mikro kopya olarak gösterilmemesi gerektiği anlamına gelir.

Statik Site Kurulumu

chromeOS.dev için, statik site oluşturucumuz olarak Nunjucks ile Eleventy (11ty) kullandık, ancak statik site oluşturucu kurmaya yönelik bu öneriler çoğu statik site oluşturucu için geçerli olmalıdır. Bir şeyin özel olduğu yerde, çağrılacaktır.

Klasör Yapısı

Klasör yapısına dayalı olarak derlenen statik site oluşturucular, alt dizin i18n yöntemini desteklemede özellikle iyidir. 11ty ayrıca global veriler içeren bir veri basamaklamasını ve sayfalama yoluyla verilerden sayfalar oluşturma aracını destekler, bu nedenle bu üç kavramı birleştirmek, aşağıdakine benzeyen temel bir klasör yapısı verir:

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

En üst düzeyde, bir sitenin sayfalarını tutacak, burada pages olarak adlandırılan bir dizin vardır. İçeride, global veri dosyalarını içeren bir _data klasörü vardır. Bu klasör, bir sonraki yardımcılardan bahsederken önemlidir. Ardından, bir _generated klasörü var. Kendi içeriğine sahip olmak yerine mevcut içerikten, küçük miktarlardaki mikrokopyadan veya her ikisinin bir kombinasyonundan oluşturulan birkaç sayfamız var. Evinizi bir ana sayfa, bir arama sayfası veya bir blog bölümünün açılış sayfası olarak düşünün. Bu sayfalar yüksek oranda şablonlu olduğundan, şablonları _generated klasöründe saklarız ve her biri için ayrı HTML veya Markdown dosyalarına sahip olmak yerine onları oradan oluştururuz. Bu klasörlerin önüne, sayfaları doğrudan altlarında çıkarmadıklarını, bunun yerine başka yerlerde sayfalar oluşturmak için kullanıldığını belirtmek için bir alt çizgi eklenir.

Sonraki, l10n alt dizinleri! Her dizin, içerdiği yerelleştirme için BCP47 dil etiketi (daha yaygın olarak yerel ayar kodu) için adlandırılmalıdır: örneğin, İngilizce için en veya Amerikan İngilizcesi için en-US . chromeOS.dev kod tabanında bunlara genellikle yerel ayarlar da denir. Bu klasörler, içeriği bir yerelleştirmeye bölen yerelleştirme alt dizinleri olacaktır. 11ty'nin veri kaskadı, dosya bir dizinin kökündeyse ve dizinle aynı şekilde adlandırılmışsa (dizin veri dosyaları olarak adlandırılır), bir dizindeki her dosyaya ve alt öğelerine veri sağlanmasına izin verir. 11ty, bu dosyadan döndürülen bir nesneyi veya bir nesneyi döndüren ve onu şablonlama için uygun hale getirilen değişkenlere enjekte eden bir işlevi kullanır, böylece bu yerelleştirmenin tüm içeriği için buradaki verilere erişimimiz olur.

Bu dosyaların sürdürülebilirliğine yardımcı olmak için, statik site yapı iskelemizin bir parçası olan l10n-data adında bir yardımcı yazdık, bu klasör yapısından yararlanarak bir dizi yerelleştirilmiş veri oluşturmak ve verilerin parça parça yerelleştirilmesine izin vermek için bu klasör yapısından yararlanır. Bunu, yerel ayara özgü bir veri dizininde, _data dizininde (dizin veri dosyasına yüklenmiş) depolayarak yapar. Örneğin, İngilizce yerel veri dizinimize bakarsanız, dil kodunu ve yazma yönünü tanımlayan locale.json gibi locale.json modellerini görürsünüz, bunlar daha sonra bizim HTML'mize, newsletter.yml için gerekli olan mikrokopiyi tanımlayan haber bülteni.yml'ye işlenir. haber bülteni kaydı ve site genelinde birden çok yerde kullanılan ve daha spesifik bir dosyaya sığmayan genel mikrokopya içeren bir microcopy.yml dosyası. Bu mikrokopinin kullanıldığı her yerde, kullanmak üzere şablonlarımıza 11 veri değişkeni enjekte ederek kullanıma sunulan bu verilerden çekiyoruz.

Mikrokopi, yönetilmesi en zor olanı olma eğilimindeyken, içeriğin geri kalanı çoğunlukla doğrudandır. İçeriğinizi, genellikle Markdown dosyalarını veya HTML'yi yerelleştirilmiş alt klasöre koyun. Klasör yapısı üzerinde çalışan statik site oluşturucular için, içeriğin dosya adı ve klasör yapısı tipik olarak bu içeriğin nihai URL'si ile 1:1 eşlenir, bu nedenle en/web/pwas.md adresindeki bir Markdown dosyası bir URL'ye çıkar. en/web/pwa . "Anahtarlar değil, değerler" yerelleştirme ilkemizi izleyerek, içerik dosyası adlarını (ve dolayısıyla yolları) yerelleştirmemeye karar verdik ve bu, aynı dosyanın yerel ayarlardaki yerelleştirme durumunu izlememizi ve kullanıcıların bunu bilmesini kolaylaştırdı. farklı yerel ayarlar arasında doğru sayfadalar.

I18n Yardımcıları

İçerik ve mikrokopyaya ek olarak, yerelleştirilmiş içerikle çalışmayı kolaylaştırmak için bir dizi yardımcı modül yazmamız gerektiğini gördük. 11ty, içeriğin oluşturulmadan önce değiştirilmesine izin veren filtre adı verilen bir konsepte sahiptir. i18n şablonlamaya yardımcı olmak için dördünü inşa ettik.

İlki bir tarih filtresidir. İçeriğimizdeki tüm tarihlerin YAML tarih değeri olarak yazılmasını standart hale getirdik çünkü bunları çoğunlukla YAML'de yazıyoruz ve bunlar tam UTC zaman damgası olarak şablonlarımızda kullanılabilir hale geliyor. full-icu modülünü ve yapılandırmasını kullanırken, işlenen içeriğin yerel ayar koduyla birlikte tarih dizesi (değiştirilen içerik), yerelleştirilmiş bir tarih oluşturmak için doğrudan Date.toLocaleString (isteğe bağlı biçimlendirme seçenekleriyle) geçirilebilir. Date.toLocaleDateString , isteğe bağlı olarak, tam yerelleştirilmiş tarih ve saat yerine hiçbir biçimlendirme seçeneği iletilmediğinde tarih bölümünü istiyorsanız kullanılabilir.

İkinci filtre, localURL bir şeydir. Bu, yerel bir URL'yi (değiştirilen içerik) ve URL'nin içinde olması gereken yerel ayarı alır ve bunları değiştirir. Örneğin, /en/linux /es/linux olarak değiştirir.

Son iki filtre, yalnızca yerel ayar kodundan yerelleştirilmiş bilgileri almakla ilgilidir. Üçüncüsü, bir yerel ayar kodunu yerel dilde dil adına dönüştürmek için iso-639-10 modülünden yararlanır. Bunu öncelikle dil seçicimiz için kullanıyoruz. Dördüncüsü, o dildeki ülkelerin bir listesini almak için iso-i18n-countries modülünü kullanır. Bunu öncelikle ülke listeleri içeren formlar oluşturmak için kullanırız.

11ty'nin filtrelere ek olarak, bir içerik gruplaması olan koleksiyon adı verilen bir konsepti vardır. 11ty, varsayılan olarak bir dizi koleksiyonu kullanıma sunar ve hatta etiketlerden koleksiyonlar oluşturabilir. Çok dilli bir sitede özel koleksiyonlar oluşturmak istediğimizi gördük. Yerelleştirmeye dayalı koleksiyonlar oluşturmak için bir dizi yardımcı işlev oluşturmaya başladık. Bu, sitemizdeki tüm içeriğe göre şablonlarımızda filtrelemeye gerek kalmadan konuma özel etiket koleksiyonlarına veya site bölümü koleksiyonlarına sahip olmak gibi şeyler yapmamızı sağlar.

Son ve en kritik yardımcımız sitemizin küresel verileriydi. Yerel kod tabanlı alt dizin yapısına dayanan bu işlev, sitenin hangi yerelleştirmeleri desteklediğini dinamik olarak belirler. {{locale-code}}.11tydata.js ve yerelleştirmeye özel içeriği içeren l10n özelliğini içeren bir global değişken olan site oluşturur. Ayrıca, mevcut tüm yerel ayarları bir dizi olarak listeleyen bir languages özelliği içerir. Son olarak, işlev, site tarafından hangi dillerin desteklendiğini ayrıntılandıran bir JavaScript dosyası ve {{locale-code}}.11tydata.js içindeki her bir giriş için yerelleştirmeye göre anahtarlanmış, tümü tarayıcı komut dosyalarımız tarafından içe aktarılmak üzere tasarlanmış ayrı dosyaların çıktısını verir. Bu dosyanın ağır yükü, statik sitemizi ön uç JavaScript'imize bağlar ve tek gerçek kaynak, zaten ihtiyacımız olan yerelleştirme bilgisidir. Ayrıca site.l10n üzerinden döngü yaparak yerelleştirmelerimize dayalı olarak programlı olarak sayfalar oluşturmamıza da olanak tanır. Bu, yerelleştirmeye özel koleksiyonlarımızla birleştiğinde, her biri için ayrı HTML sayfaları tutmadan yerelleştirilmiş ana sayfa ve haber açılış sayfaları oluşturmak için 11ty'nin sayfalandırmasını kullanmamıza izin verdi.

Çözüm

Uluslararasılaştırma ve yerelleştirmeyi doğru yapmak zor olabilir; Farklı stratejilerin ve karmaşıklığı nasıl etkilediğini anlamak, bunu kolaylaştırmak için kritik öneme sahiptir. Statik siteler, alt dizinler için doğal olarak uygun bir i18n stratejisi seçin, ardından üretilen içerikten i18n ve i10n parçalarını otomatikleştirmek için bundan araçlar oluşturun. Sağlam içerik ve mikroskop modelleri oluşturun. Sunucudan bağımsız yerelleştirme için hizmet çalışanlarından yararlanın. Yalnızca ekran boyutuna değil, içeriğe de duyarlı bir tasarımla hepsini birbirine bağlayın. Sonunda, tüm yerel ayarlardaki kullanıcılarınızın seveceği, yazarlar ve çevirmenler tarafından basit tek yerel bir siteymiş gibi sürdürülebilen bir siteniz olacak.