Çok dilli bir bilgi portalı planlamayı, kurmayı ve optimize etmeyi öğrenin: yapı, çeviriler, gezinme, SEO ve sürekli güncellemeler.

Çeviri araçları veya bir dil seçiciyi düşünmeden önce, portalınızın amacı ve kimlere hizmet etmesi gerektiği konusunda net olun. Bu adım, ileride paranızı boşa harcamamaya yardımcı olur; çünkü “her şeyi çevir” kararlarının gerçek kullanıcı ihtiyaçlarıyla uyuşmamasını engeller.
Çok dilli bilgi portalları genelde birkaç kalıba uyar:
Bir cümlelik bir hedef yazın, örneğin: “Halkın doğrulanmış hizmetleri bulmasına ve uygunluk şartlarını anlamasına yardımcı olmak.” Bu hedef, öncelikle nelerin çevrileceğini filtrelemenize yardımcı olur.
Diller sadece birer onay kutusu değildir. Şunları belirleyin:
Analitik veya destek kayıtlarınız varsa, hangi dillerin ve konuların en fazla talep oluşturduğunu doğrulamak için kullanın.
Tüm içerikler eşit değerde değildir. Pratik bir yaklaşım, her içerik türünü etiketlemektir:
Ayrıca hangi içeriklerin tam yerelleştirme (anlaşılması için yeniden yazım) gerektirdiğini ve hangilerinin temel çeviri ile yetinebileceğini belirleyin.
Küçük sayıda ölçülebilir sonuç seçin, örneğin:
Bu metrikler dilleri önceliklendirmede ve yayına aldıktan sonra portalın işe yarayıp yaramadığına kanıt sağlamada yardımcı olur.
Bir çok dilli bilgi portalı yapısı üzerinde başarılı ya da başarısız olur. Herhangi bir şeyi çevirmeden önce sitenin şeklinin net, tutarlı ve diller arasında yeniden kullanılabilir olduğundan emin olun.
İçerik türlerinizi ve aralarındaki ilişkileri listeleyin. Çoğu portal için bu, makaleler, kategoriler, etiketler, yardım dokümanları/S.S.S. ve formları (iletişim, geri bildirim, bülten, gönderimler) içerir. Ayrıca yasal sayfalar, duyurular, indirilebilir kaynaklar veya konuma dayalı sayfalar gibi özel öğeleri de not edin.
Her şeyi bir arada gördüğünüzde, hangi türlerin her dilde olması gerektiğine (örn. temel yardım dokümanları) ve hangilerinin isteğe bağlı olabileceğine (örn. yerel haberler) karar verebilirsiniz.
Çevrildiğinde bile anlamı koruyan bir site haritası hedefleyin. Basit bir yapı korumak, hem bakımını hem de kullanıcıların dil değiştirirken gezinmesini kolaylaştırır.
Üst düzey bölümlerin sayısını düşük tutun ve zamanla “karışık” hale gelecek kategoriler oluşturmaktan kaçının. Büyüme alanına ihtiyacınız varsa, yeni üst düzey öğeler eklemek yerine mevcut bir bölümün alt seviyesinde planlayın.
Etiketlerin görünümü değişse bile kategori anlamlarının diller arasında tutarlı olmasını sağlayın. Bu, gezinme, arama filtreleri, analitik ve paylaşılan şablonlar için önemlidir.
Etiketlerle dikkatli olun: hızla çoğalırlar, tutarlı çevrilmesi zordur ve sıklıkla yinelenenler oluşur (örn. “how-to” vs “guide”). Etiket kullanıyorsanız kurallar belirleyin: kim oluşturabilir, ne zaman birleştirilir ve nasıl çevrilir.
Erken şu modellerden birini seçin:
Dil-spesifik bölümlere izin verirseniz, portalın zamanla üç farklı siteye dönüşmesini önlemek için bunları net olarak belgeleyin.
URL deseniniz daha sonra değiştirmesi en zor çoklu dil kararıdır. Daha fazla dil, bölüm ve katkıda bulunan eklendikçe net kalan bir yapı seçin.
1) Alt dizinler: /en/, /es/, /fr/
Birçok bilgi portalı için en yaygın seçim budur; çünkü her şey tek bir domain altında yaşar. Yönetimi daha basittir, tek bir analytics mülkü ile izlemek kolaydır ve genellikle operasyonel olarak en az maliyetlidir.
2) Alt alanlar: en.example.com, es.example.com
Ekipler, altyapı veya sürüm döngüleri lokale göre ayrılmışsa kullanışlıdır. Dezavantajı, her alt alanın kullanıcılara ve araçlara ayrı bir site gibi gelmesi ve SEO, analitik, çerezler ve yönetişim açısından ek yük getirmesidir.
3) Ayrı alanlar: example.es, example.fr (veya tamamen farklı domainler)
Güçlü ülke markalaması, yerel yasal gereksinimler veya yerel barındırma gerekiyorsa en iyisidir. Ancak en çok iş gerektirir: birden fazla alan, ayrı otorite oluşturma ve daha karmaşık yönetim.
Çoğu portal için alt dizinler (örn. /en/, /es/) kullanın ve içerik yapısını diller arasında aynı tutun.
Lokaller yarı-bağımsız yönetiliyorsa alt alanlar düşünün. Ayrı alanları sadece güçlü iş veya yasal bir neden olduğunda tercih edin.
İnsan dostu slug’lar kullanın, stabil tutun ve hiyerarşiyi yansıtın:
/en/help/getting-started//es/ayuda/primeros-pasos/Slug’ların çevrilip çevrilmeyeceğine karar verin (kullanıcılar için genelde çevirmek daha iyidir) ve editörlerin tutarsızlığa düşmemesi için kuralı belgeleyin.
Tek bir varsayılan davranış belirleyin (örn. /'i /en/'e yönlendir veya bir dil seçici göster) ve tutarlı olun.
Sadece takip parametreleri veya alternatif yollarla farklılaşan sayfa kopyalarından kaçının. Emekliye ayrılan URL’ler için 301 yönlendirmesi, kaçınılmaz çoğaltmalar için canonical etiketleri kullanın (ör. yazdırma görünümleri veya filtrelenmiş listeler).
Kullanıcılar diller arasında sorunsuz geçiş yapabildiğinde portal “kolay” hissedilir. Dil geçiş düğmesi süs değildir—tüm sitede tutarlı olması gereken temel bir gezinme öğesidir.
Düğmeyi başlıkta görünür şekilde yerleştirin, böylece aramadan gelen açılış sayfalarında bile görülebilir. Uzun sayfalarda kullanıcılar için footer’da ikinci bir geçiş düğmesi koyun.
Bayraklar yerine tanınabilir dil adlarını kullanın (“English”, “Español”, “Français”). Bayraklar ülkeleri, dilleri temsil etmez ve kafa karışıklığı yaratır.
Tarayıcı ayarı veya konuma göre öneride bulunabilirsiniz ama asla kullanıcıyı hapsetmeyin. Yaygın bir desen: "Español tercih eder misiniz? İspanyolcaya geçin." şeklinde küçük bir banner. Kullanıcı kapattıysa belli bir süre tekrar göstermeyin.
Kullanıcı bir dili seçince çerezle (ve hesap varsa profilde) saklayın. Amaç: kullanıcı bir kez dil seçtiğinde site o dilde kalmalı, kullanıcı değiştirene kadar.
Eksik sayfalar için plan yapın. Bir sayfa bir dilde yoksa:
Bu, çıkmazları önler ve çeviriler ilerlerken güveni korur.
CMS tercihiniz çok dilli yayıncılığı ya rutin haline getirir ya da her güncellemeyi mini bir projeye dönüştürür. Platformları karşılaştırmadan önce ne yayınlayacağınızı (haberler, rehberler, PDF’ler, uyarılar), ne sıklıkta değiştiğini ve her dili kimin yönettiğini yazın.
"Çok dilli web sitesi" sadece çevrilmiş sayfa metni değildir. Platformun dil başına şunları yönetebildiğinden emin olun:
Ayrıca CMS’in "eksik çeviriler"i nasıl yönettiğini kontrol edin. İngilizce güncelleme yayımlandığında İspanyolca sürüm bozulmadan çevrilme sürecinde kalabiliyor mu?
Geleneksel CMS (WordPress, Drupal), barındırılan kurucular veya headless CMS fark etmeksizin aynı yetenekleri değerlendirin:
Headless CMS düşünüyorsanız, ön yüzü sürdürecek birinin olduğundan emin olun; yoksa yönetilen bir CMS daha uygun olabilir.
Eğer portali sıfırdan inşa ediyorsanız, hızlı prototip ve tam yığın teslimi için sohbet üzerinden yapı tanımlamaya izin veren bir vibe-coding platformu olan Koder.ai pratik bir seçenek olabilir: çok dilli IA’yı, URL yapısını (ör. /en/, /es/) ve temel şablonları sohbette tanımlayıp planlama modu, snapshot ve geri alma ile yineleyebilirsiniz. React tabanlı bir ön yüz ile Go/PostgreSQL arka ucu istediğiniz gibi hızlıca inşa edip kaynak kodunu dışa aktarabilirsiniz.
Çok dilli portallar sıkı yönetişimden fayda görür. Arayın:
Bu, yanlış dilde yanlış düzenlemelerin önüne geçer ve onay süreçlerini tutarlı kılar.
CMS’inizin şu araçlarla iyi oynadığından emin olun:
Bir pilot çalışması—birkaç sayfa, bir menü ve meta verilerin uçtan uca çevrilmesi—bir özellik listesi kadar bilgi verir.
Birçok dilli bilgi portalı ancak her dil tutarlı şekilde güncellendiğinde güvenilir kalır. Bu sadece “çeviriye gönder” demek değildir; net kurallar, sahiplik ve öngörülebilir bir boru hattı gerekir.
Tüm çevirmenlerin ve editörlerin takip edebileceği hafif bir stil rehberiyle başlayın. Pratik tutun:
Bu, aynı kavramın üç farklı çeviriye dönüşmesini azaltır ve arama ile destek işlemlerini kolaylaştırır.
Çoğu portal karışık bir model kullanır:
Hangi içerik türünün hangi yola gideceğini tanımlayın. Emin değilseniz önce daha sıkı (daha fazla insan incelemesi) başlayın ve kaliteye göre gevşetin.
El değişimlerini açık yapın: çevirmen → editör → yayıncı.
Editörler anlam, ton, terminoloji ve temel kullanılabilirliği (linkler, başlıklar, CTA’lar) kontrol etmelidir. Yayıncı, sayfanın doğru render edildiğinden ve kaynak versiyonun niyetine uyduğundan emin olur.
Kabul kriterleri ekleyin: “Eksik dize yok, tüm butonlar çevrildi, ekran görüntüleri kullanılmadı veya yerelleştirildi, meta veriler dahil.”
Bir dilin aylarca geride kalması güven kaybettirir. Rutin oluşturun:
Tutarlılık kahramanlıklardan daha etkilidir: düzenli kontroller ve net sahiplik, dillerin birbirinden kopmasını engeller.
Mükemmel çeviriler yapılmış olsa bile tasarım tek dili varsayıyorsa site “yanlış” hissedebilir. İyi haber: çoğu yerelleştirme düzeltmesi erken planlandığında basittir.
Bazı diller metni önemli ölçüde uzatabilir (Almanca genelde daha uzundur; Rusça satır uzunluğunu etkileyebilir; bazı Asya dilleri okunabilirlik için daha büyük punto gerektirebilir). Sözcük diziliği de değişir—"Daha fazla bilgi" gibi butonlar daha uzun bir ifade olabilir.
Tasarımı esnek yapın:
İngilizce için güzel görünen bir font, Kiril, Yunanca, Vietnamca diyakritikleri veya diğer gerekli glifleri içermeyebilir. Tam karakter kümesini destekleyen bir font ailesi (veya eşleşen set) seçin.
Pratik kontroller:
Arapça veya İbranice yol haritanızdaysa, şimdi RTL planlayın—sonradan eklemek zahmetli olur. RTL sadece metni ters çevirmek değildir; navigasyon sırası, ikonlar ve hizalama etkilenir.
Önemli noktalar:
Formatlama güvenin bir parçasıdır. Bilgileri kullanıcıların beklediği şekilde gösterin:
Bunları tasarım öğesi olarak görün: yeterli alan ayırın, belirsiz formatlardan kaçının ve sayfalar ile formlar arasında tutarlılığı koruyun.
Çok dilli SEO, arama motorlarının hangi sayfanın hangi dili temsil ettiğini anlamasına yardımcı olmaktan ibarettir; bazen hangi bölgeye yönelik olduğu da bildirilmeli. Her dil versiyonunun gerçekten kullanışlı olduğundan emin olun.
Sadece gövde metnini çevirmeyin. Her dil versiyonunun kendi:
Kelime kelime çeviri yerine doğal ifadeler hedefleyin. Kelimesi kelimesine başlık, gösterim oranını olumsuz etkileyebilir.
Google'ın doğru dil versiyonunu göstermesi ve "çoğaltılmış içerik" karışıklığını önlemek için hreflang ekleyin.
Temel kurallar:
/en/guide ve /es/guide), sadece ana sayfaları değilen, es, fr-CA gibi). Bir global varsayılan için x-default düşününBölge hedefleme konusunda emin değilseniz, dil-oynaklı ayırmadan önce dil-only kullanın.
Arama motorları derinlik ve fayda sunan içeriği ödüllendirir. Düzenlenmemiş makine çevirisiyle dolu onlarca sayfa, düşük kaliteli sinyaller oluşturabilir.
Bunun yerine:
Platformunuz destekliyorsa her dil için ayrı sitemap’lar (veya bir sitemap dizini) oluşturun. Bu, keşfi hızlandırır ve indeksleme sorunlarını locale göre debug etmeyi kolaylaştırır.
Son olarak, Google Search Console’da dil dizin/alt alan bazında performansı doğrulayın ve ölçeklemeden önce sorunları düzeltin.
Bir çok dilli bilgi portalı “bulunabilirlik” üzerine kurulur. Ziyaretçiler aynı konuyu kendi dilinde aynı zihinsel modelle bulamıyorsa, içeriğin bulunmadığını sanırlar.
Erken kararlaştırın: site içi arama dil başına mı yoksa çapraz dil mi olacak?
Emin değilseniz, varsayılan olarak dil başına ile başlayın ve isteğe bağlı olarak "diğer dilleri dahil et" seçeneği ekleyin.
Tutarlı bir varsayılan koyun: kullanıcı Fransız versiyonunda gezerken arama önce Fransızca sonuçları getirmeli. Bu en yaygın siniri—başlık yazıp başka dilde içerik görmek—azaltır.
Küçük UI ipuçlarıyla destekleyin:
Gezinme sadece menüler değildir. Kategori isimleri, filtreler, konu etiketleri, breadcrumb ve "ilgili içerik" bunun bir parçasıdır. Bunları serbest metin gibi değil, kontrollü bir sözlük gibi yönetin.
Basit bir paylaşılan taksonomi listesi oluşturun:
Bu, zamanla "Yardım Merkezi"nin "Destek", "Asistanlık" ve "Müşteri Yardım" gibi farklı biçimlere dönüşmesini engeller.
404 sayfanız, özellikle çeviri veya yeniden yapılanma sırasında kırılan bağlantılarda bir gezinme aracı olmalıdır.
İyi bir çok dilli 404 şunları yapmalı:
Popüler sürekli güncel sayfalarınız varsa “En çok ziyaret edilen kaynaklar” gibi önerilerle oturumu hızlıca kurtarın.
Çok dilli portal başarıyı son adımlarda kaybederse başarısız olur: talep gönderme, güncelleme aboneliği, kaynak indirme veya sorun bildirme gibi anlar karışık dil deneyimleriyle kolayca bozulur. Bu yolculuklar UI metni, doğrulama kuralları, e-posta şablonları ve yasal bildirimleri karıştırır—yarım çeviri hızla hatalı hissettirir.
Form deneyimini uçtan uca yerelleştirin:
Ayrıca formlar tarafından tetiklenen işlem e-postalarını (onay mailleri, şifre sıfırlama, ticket bildirimleri) yerelleştirin. Eğer kullanıcı profilde tercih dil seçebiliyorsa, e-postalar için o tercihi kullanın; kullanıcının rastgele gezdiği site dilini değil.
Erişilebilirlik tek seferlik bir iş değildir ve sadece kaynak dilde yapılmamalıdır. Her çeviri metin uzunluğunu ve anlamını değiştirebilir, bu da kullanılabilirliği etkiler.
Her dilde kontrol edin:
İkonlar (örn. bilgi tooltip’i) kullanıyorsanız açıklamanın ekran okuyucular için çevrildiğinden emin olun.
Çerez/onay panelleri ve yasal sayfalar bölgeye göre değişebilir. Metni yerelleştirin ve davranışın (ne engelleniyor/engellenmiyor) yerel gereksinimlerle uyduğundan emin olun. Gerekirse bölge-spesifik sayfalar yayınlayın: Gizlilik Politikası, Kullanım Şartları, veri talep yönergeleri gibi.
Yayına almadan önce yerel konuşan kişilerle görev tabanlı testler yapın: bir form gönderin, her hatayı tetikleyin, onay akışını tamamlayın ve e-posta içeriklerini doğrulayın. Gerçek kullanım, otomatik kontrollerin göremeyeceği garip ifadeleri, eksik çevirileri ve kafa karıştıran adımları ortaya çıkarır.
Çok dilli bir bilgi portalı yayına alındıktan sonra bitmez. Güvenilir kalan ile zamanla uyumsuz hale gelen site arasındaki fark, dil başına sonuçları nasıl ölçtüğünüz ve güncellemeler konusunda ne kadar disiplinli olduğunuzdur.
Yeni sayfalar (veya büyük bir yeniden tasarım) yayımlamadan önce tekrarlanabilir bir kontrol listesi kullanın:
Bunu bir kapı olarak görün: bir dil eksikse ya tamamlayın ya da o dildeki sayfayı kasıtlı olarak gizleyin.
Raporlamayı "İspanyolca nasıl gidiyor?" sorusunu cevaplayacak şekilde kurun, sadece "site nasıl gidiyor?" demeyin. Dil bazında izleyin:
Bu, bir sorunun çeviri kalitesi mi (yüksek çıkış) yoksa keşfedilebilirlik mi (gösterim yok) olduğunu ortaya koyar.
Çok dilli siteler sessizce bozulur: yeni bir İngilizce sayfa yayına girer, ama Fransızcası 404 verir; bir slug sadece bir lokalde değişir. Şunlar için uyarılar ekleyin:
İçeriği ve SEO’yu uyumlu tutmak için üç aylık denetimler planlayın:
Tutarlılık kahramanlıklardan daha etkilidir—küçük, düzenli kontroller çok dilli portalınızı zaman içinde güvenilir kılar.
Bir cümlelik portal hedefi yazın ve en önemli kullanıcı yolculuklarınızı listeleyin (ör. uygunluk, nasıl başvurulur, acil bilgi). Ardından içerik türlerini şu şekilde etiketleyin:
Bu, "her şeyi çevirelim" harcamalarını önler ve en çok önem taşıyan yerlerde kaliteyi korur.
Sayfa görüntülemelerden öte sonuçlara bağlı metrikler seçin. Yaygın seçenekler:
Her dil için hedefler belirleyin ki hangi lokasyonun görünürlük veya kullanılabilirlik açısından geri kaldığını görebilesiniz.
Yayınladığınız içerik türlerinin bir envanterini çıkarın (makaleler, rehberler, S.S.S., dizinler, formlar, yasal sayfalar). Sonra tüm dillerde tutarlı kalacak bir site haritası tasarlayın:
Tutarlı bir yapı gezinmeyi, aramayı, analitiği ve çeviri iş akışlarını çok daha kolay yönetir.
Taksonomiyi kontrollü bir sözlük olarak ele alın. Kanonik kavramları (ör. “Kamu sağlığı”) tanımlayın ve her dil için onaylanmış çevirilerini tutun.
Pratik ipuçları:
Bu, farklı sayfalarda benzer bölümlerin farklı, kafa karıştırıcı etiketlere dönüşmesini önler.
Çoğu portal için alt dizinler (ör. /en/, /es/) varsayılan öneridir. Avantajları:
Alt alanları (subdomain) yalnızca lokaller yarı-bağımsız işletiliyorsa düşünün; ayrı alan adları ise güçlü ülke markalaması veya yasal/operasyonel gereksinimler için seçilmelidir.
Tek bir varsayılan davranış belirleyin ve her yerde uygulayın:
/ ne yapar (varsayılan dile yönlendirir mi yoksa seçim gösterir mi) kararlaştırınAyrıca her sayfanın gerçek dil eşdeğerine bağlantı verdiğinden emin olun (sadece anasayfaya değil) ki dil değiştirmek kullanıcı yolunu bozmasın.
Header’da her sayfada görünen bir dil seçici koyun (footer’a yedek bir düğme de ekleyin). “English”, “Español” gibi dil adlarını tercih edin; bayrak kullanmayın.
Otomatik algılama için:
Bu, geçişi öngörülebilir kılar ve kullanıcıyı rahatsız etmez.
Kullanıcıyı çıkmaza sokmayın. Bir sayfa çevrilmemişse:
Bu, çeviriler hâlâ ilerlerken güveni korur ve geçiş düğmesinin “bozuk” gibi görünmesini engeller.
CMS’inizin dil başına yönetebildiğinden emin olun:
Ayrıca çevirileri orijinal sayfaya bağlama, dil başına iş akışları (taslak → inceleme → yayın) ve seçtiğiniz URL desenini destekleme yeteneğini kontrol edin.
Her dilde sadece gövde metnini değil, şu öğeleri de yerelleştirin:
Ayrıca hreflang kullanarak eşdeğer sayfaları birbirine bağlayın (karşılıklı olmalı). Büyük hacimlerde, düzeltilmemiş makine çevirisiyle dolu sayfalar yayımlamaktan kaçının; önce en önemli sayfaları yapın ve dil kapsamını trafğe/kaliteye göre genişletin.