11 Eylül 2011, Pazar
Globalleşiyorsunuz ve web sitenizin de buna ayak uydurması gerekiyor. Metni çevirtip işi bitirmek kadar basit bir süreç gibi görünebilir, değil mi? Muhtemelen öyle değil. Google Web Yöneticisi Ekibi, 40’tan fazla dile yerelleştirilmiş siteler oluşturuyor; bu nedenle sayfalarımızı hem diğer dillerde hem de bölgelerde yayına alırken dikkate aldığımız bazı noktaları burada paylaşıyoruz.
(Yalnızca İngilizce içerik sunduğunuz için bu sorunlardan muaf olduğunuzu düşünseniz bile, İngilizce dışındaki dilleri konuşan ziyaretçiler içeriğinizi kendi dillerinde görüntülemek için Google Çeviri gibi araçlar kullanıyor olabilir. Bu trafik analiz panelinizde görünecektir, böylece kaç ziyaretçinin sitenizi amaçlandığı şekilde görüntülemediği hakkında bir fikir edinebilirsiniz.)
Daha fazla dil != daha fazla HTML şablonu
Bunu ne kadar vurgulasak azdır: Tüm dil sürümleri için aynı şablonu yeniden kullanın ve şablonunuzun HTML yapısını her zaman basit tutmaya çalışın.
HTML kodunu tüm diller için aynı tutmanın bakım konusunda avantajları vardır. Hataları düzeltmek için her dilin HTML koduyla uğraşmak ölçeklenebilir bir yöntem değildir; sayfa kodunuzu mümkün olduğunca temiz tutun ve stil sorunlarını CSS ile çözün. Temiz kodun sadece bir faydasından bahsetmek gerekirse: çoğu çeviri aracı, çevrilebilir içerik dizelerini HTML belgesinden ayrıştırır ve HTML iyi yapılandırılmış ve geçerli olduğunda bu iş çok daha kolaylaşır.
Metin uzunluğu ne kadar olmalı?
Tasarımınız metnin sabit boyutlu öğelerle uyumlu olmasına dayanıyorsa, metni çevirmek her şeyi altüst edebilir. Örneğin, sol taraftaki navigasyon metniniz birçok dilde çok daha uzun metin dizelerine dönüşebilir; aynı içerik için İngilizce ve Felemenkçe navigasyon arasındaki dize uzunluğu farkına bir göz atın. Navigasyon başlıklarının birden fazla satıra taşabileceğini göz önünde bulundurarak satır yüksekliğinizi buna göre ayarlayın (bunu en başta İngilizce navigasyon metninizi oluştururken de düşünmekte fayda var).
Değişken kelime uzunlukları, form etiketlerinde ve kontrollerinde özel sorunlara yol açar. Örneğin, form düzeniniz etiketleri solda, alanları sağda görüntülüyorsa, daha uzun metin dizeleri iki satıra taşabilirken, daha kısa metin dizeleri form giriş alanlarıyla ilişkisiz görünebilir; her iki senaryo da tasarımı bozar ve formun okunabilirliğini engeller. Ayrıca, sağdan sola (RTL) düzenler için ihtiyaç duyacağınız ekstra stilleri de düşünün (buna daha sonra değineceğiz). Bu nedenlerle, kolay okunabilirlik ve diller arasında iyi bir şekilde çevrilebilecek stiller için formları, etiketler alanların üzerinde olacak şekilde tasarlıyoruz.

Ayrıca sabit yükseklikli sütunlardan kaçının; düzeninizi eşleşen yükseklikte kutu arka planlarıyla düzene sokmaya çalışıyorsanız, metniniz çevrildiğinde metnin sadece İngilizce içeriğinizi sığdıracak kadar yüksek olan alanları aşması muhtemeldir. Tasarımınızda kullanmayı planladığınız UI öğelerinin daha fazla veya daha az metin olduğunda çalışıp çalışmayacağını düşünün; örneğin, yatay ve dikey sekmeler gibi.
Diğer taraftan
Çift yönlü (bidirectional) HTML için kaynak düzenleme sorunlu olabilir çünkü birçok düzenleyici Unicode çift yönlü algoritmasını destekleyecek şekilde oluşturulmamıştır (sorunlar ve çözümler üzerine daha fazla araştırma). Kısacası, işaretlemenizin görüntülenme şekli bozulabilir:
Günlük kullanımımız, şu düzenleyicilerin çift yönlü düzenleme için şu anda makul çözümler sunduğunu göstermiştir: özellikle Coda ve ayrıca Dreamweaver, IntelliJ IDEA ve JEditX.
RTL dilleri için tasarım yaparken, ihtiyacınız olan desteğin çoğunu temel CSS’e yerleştirebilir ve html öğesinin yön özniteliğini (geriye dönük uyumluluk için) body öğesindeki bir sınıf ile birlikte kullanabilirsiniz. Her zaman olduğu gibi, tüm stilleri tek bir temel stil sayfasında tutmak daha iyi bir bakım kolaylığı sağlar.
Dikkat edilmesi gereken bazı temel stil sorunları: sağa yaslanan tüm öğelerin sola yaslanması gerekecektir ve tam tersi; bir öğenin bir tarafına uygulanan ekstra dolgu veya kenar boşluğu genişliklerinin geçersiz kılınması ve değiştirilmesi gerekecektir ve tüm text-align öznitelikleri tersine çevrilmelidir.
Genellikle aşağıdaki yaklaşımı kullanıyoruz; eski tarayıcılarla uyumlu olduğu için html[dir=rtl] CSS seçicisi yerine body etiketi üzerinde bir sınıf kullanmayı tercih ediyoruz:
Öğeler:
Soldan sağa (varsayılan) stil:
Sağdan sola stil:
(Bunu İngilizce ve Arapça dillerinde çalışırken görebilirsiniz.)
Bu konuyla ilgili son bir not: Sağdan sola dil sayfalarınız için hazırladığınız içeriğin çoğu, tamamen RTL olmaktan ziyade çift yönlü olacaktır, çünkü bazı dizelerin LTR yönünü koruması gerekecektir; örneğin, Latin alfabesindeki şirket adları veya telefon numaraları. Tarayıcının bunu temel olarak RTL olan bir belgede doğru şekilde işlemesini sağlamanın yolu, gömülü metin dizelerini, yönü ayarlamak için bir öznitelik kullanan satır içi bir öğeyle sarmalamaktır, şöyle:
Başlık öğeleri veya mesaj istemleri için JavaScript tarafından oluşturulan kaynak kod gibi dir özniteliğini bağlayabileceğiniz bir HTML kapsayıcınızın olmadığı durumlarda, yönü ayarlamak için bu eşdeğeri kullanabilirsiniz; burada ‫ ve ‬ sağdan sola gömme için Unicode kontrol karakterleridir:
JavaScript kodunda örnek kullanım:
(Daha fazla ayrıntı için W3C’nin Arapça, İbranice ve diğer sağdan sola yazılan diller için HTML oluşturma ve sağdan sola yazılan dilleri yazma hakkındaki makalelerine bakın.)
Bana hepsi Yunanca geliyor…
Daha önce Latin alfabesi dışındaki karakter setleriyle (Kiril, Yunanca ve sayısız Asya ve Hint dilleri) hiç çalışmadıysanız, hem düzenleyicinizin hem de tarayıcınızın içeriği amaçlandığı gibi görüntülemediğini fark edebilirsiniz.
Düzenleyici ve tarayıcı kodlamalarınızın UTF-8 (önerilen) olarak ayarlandığından emin olun ve HTML şablonunuza bir <span> öğesi ve html öğesinin lang özniteliğini eklemeyi düşünün; böylece tarayıcılar sayfanızı oluştururken ne bekleyeceklerini bilirler. Bunun, tüm Unicode karakterlerinin doğru görüntülenmesini sağlama gibi ek bir faydası da vardır, bu nedenle é (é) gibi HTML varlıklarını kullanmak gerekmeyecek ve değerli baytlardan tasarruf edeceksiniz! Sorun yaşıyorsanız W3C’nin karakter kodlama eğitimine göz atın; sorunların derinlemesine açıklamalarını içerir.
İsimlendirme üzerine bir not
Son olarak, birkaç dil sürümü oluştururken isimlendirme kuralları hakkında pratik bir ipucu. ISO 639-1 dil kodları gibi bir standart kullanmak, aynı belgenin birkaç dil sürümüyle uğraşmaya başladığınızda yardımcı olur.
Geleneksel bir standart kullanmak, kullanıcıların sitenizin yapısını anlamalarına yardımcı olacağı gibi, siteyi geliştirebilecek tüm web yöneticileri için daha sürdürülebilir hale getirecektir. Ayrıca diğer site varlıkları (logo görselleri, PDF belgeleri) için dil kodlarını kullanmak, dosyaları hızlı bir şekilde tanımlamak için kullanışlıdır.
URL yapıları ve çok bölgeli web siteleriyle çalışma ve çok dilli web siteleriyle çalışma ile ilgili diğer konular hakkındaki tavsiyeler için önceki Webmaster Central gönderilerine bakın.
Günlük olarak uğraştığımız temel zorlukların bir özeti bu; ancak iyi yapılandırılmış HTML ve sağlam CSS için önceden planlama yapmanın ve çalışmanın yerelleştirme sırasında meyvelerini verdiğini garanti edebiliriz!
Biz bunu nasıl uyguluyoruz
Google announcements age. We keep this post here for the record, and we note for clients whether the behaviour it describes still applies today or has since been superseded.
İlgili hizmetler