28 May 2025·8 dk

Çok Dilli Bir Bilgi Portalı İçin Web Sitesi Nasıl Oluşturulur

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

Çok Dilli Bir Bilgi Portalı İçin Web Sitesi Nasıl Oluşturulur

Hedefler, kitleler ve dil öncelikleri ile başlayın

Ç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.

Portalın hedefini tanımlayın

Çok dilli bilgi portalları genelde birkaç kalıba uyar:

  • Haberler ve güncellemeler (zamanlama önemli; eski içerikler tam çeviri gerektirmeyebilir)
  • Rehberler ve kaynaklar (sürekli güncel sayfalar yerelleştirmeden en çok fayda sağlar)
  • S.S.S. ve destek (talep sayısının azalması ölçülebilir bir sonuçtur)
  • Dizinler (hizmetler, iletişimler veya kuruluş listeleri; doğruluk ve bölgesel farklılıklar önemlidir)

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.

Kitleleri ve bölgeleri listeleyin (ve gerçekten neye ihtiyaçları olduğu)

Diller sadece birer onay kutusu değildir. Şunları belirleyin:

  • Birincil kullanıcı gruplarınız (sakinler, ziyaretçiler, profesyoneller, öğrenciler, ortaklar)
  • Hizmet verdiğiniz bölgeler (bir dil sadece belirli şehirler veya ülkeler için gerekebilir)
  • Ziyaret amaçları (kısa cevaplar, derin araştırma, formlar, iletişim bilgileri)

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.

Ne çevrilmeli, ne tek dilde kalabilir karar verin

Tüm içerikler eşit değerde değildir. Pratik bir yaklaşım, her içerik türünü etiketlemektir:

  • Çevrilmeli: kritik yolculuklar (nasıl başvurulur, uygunluk, acil bilgi, temel politikalar)
  • Çevrilmeli (olmalı): yüksek trafikli rehberler, en önemli S.S.S., onboarding sayfaları
  • Tek dilde kalabilir: dahili duyurular, niş güncellemeler, teknik dokümantasyon

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.

Başarı metriklerini erken belirleyin

Küçük sayıda ölçülebilir sonuç seçin, örneğin:

  • Lokalize sayfalara gelen arama trafiği
  • Dil bazında kayıtlar veya kaynak indirmeleri
  • Önemli rehberlerde sayfada geçirilen süre / kaydırma derinliği
  • Yanlış anlamalardan kaynaklanan daha az destek talebi

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.

Çoklu diller için bilgi mimarisini planlayın

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.

Bir envanterle başlayın (gerçekte ne yayımlıyorsunuz)

İç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.

Her yerde işe yarayan bir site haritası oluşturun

Ç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.

Taksonomiyi standartlaştırın: kategoriler ve etiketler

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.

İçerik eşitliği mi yoksa dil-spesifik bölümler mi?

Erken şu modellerden birini seçin:

  • Aynı yapı + her dilde aynı içerik (destek portalları ve dokümantasyon için en iyi)
  • Aynı yapı + kısmen çevrilmiş içerik (bloglar ve kaynak merkezleri için yaygın)
  • Dil-spesifik bölümler (kanunlar, hizmetler veya kullanıcı ihtiyaçları farklıysa kullanışlı)

Dil-spesifik bölümlere izin verirseniz, portalın zamanla üç farklı siteye dönüşmesini önlemek için bunları net olarak belgeleyin.

Ölçeklenen bir dil URL yapısı seçin

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.

Ana URL seçenekleri (ne anlama gelir)

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.

Varsayılan öneri

Ç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.

URL’leri okunabilir ve tutarlı tutun

İ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.

Yönlendirmeler ve canonical kuralları

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).

Dil geçişi ve kullanıcı deneyimini tasarlayın

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.

Geçiş düğmesini nereye koymalı ve nasıl etiketlemeli?

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.

Otomatik algılama: yardımcı ama kontrol edilemez olmamalı

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ının tercihini hatırlayın

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.

İçerik çevrilmediğinde geri dönüş yolları

Eksik sayfalar için plan yapın. Bir sayfa bir dilde yoksa:

  • Kullanıcının seçtiği dilde kalın ve sayfanın çevrilmediğini nazikçe belirtin
  • Varsayılan dildeki versiyona açık bir bağlantı sunun
  • Alternatifler gösterin: ilgili kategori, arama sonuçları veya anasayfa

Bu, çıkmazları önler ve çeviriler ilerlerken güveni korur.

Çok dilli bir portal için doğru CMS ve araçları seçin

Tam yığını sohbet içinde oluşturun
Bir sohbetten React ön yüzü ile Go ve PostgreSQL arka ucu oluşturun.

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 temellerle başlayın

"Çok dilli web sitesi" sadece çevrilmiş sayfa metni değildir. Platformun dil başına şunları yönetebildiğinden emin olun:

  • Sayfalar ve yeniden kullanılabilir bloklar (başlıklar, footer, bannerlar)
  • Menüler ve gezinme etiketleri
  • SEO meta verileri (başlıklar, açıklamalar, sosyal paylaşım metinleri)
  • Medya alanları (altyazı, alt metin)

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?

CMS seçenekleri: nelere bakmalı

Geleneksel CMS (WordPress, Drupal), barındırılan kurucular veya headless CMS fark etmeksizin aynı yetenekleri değerlendirin:

  • Net içerik modelleme: Çevirileri orijinal sayfaya bağlayabilmelisiniz ve durumunu kolayca görebilmelisiniz.
  • Esnek iş akışları: Dil başına Taslak → İnceleme → Onay → Yayın kolayca uygulanabilmeli.
  • Ölçeklenebilir URL desteği: CMS seçtiğiniz dil URL yapısını desteklemeli.

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.

İzinler, roller ve editoryal kontrol

Çok dilli portallar sıkı yönetişimden fayda görür. Arayın:

  • Sınırlı izinlere sahip çevirmen hesapları
  • Dil başına gözden geçiren/düzenleyen roller
  • Denetim geçmişi (kim neyi, ne zaman değiştirdi)

Bu, yanlış dilde yanlış düzenlemelerin önüne geçer ve onay süreçlerini tutarlı kılar.

Zaman kazandıran entegrasyonlar

CMS’inizin şu araçlarla iyi oynadığından emin olun:

  • Çeviri yönetimi (dışa/ içe aktarma, çeviri hafızası, sözlük desteği)
  • Formlar (yerelleştirilmiş onay mesajları ve bildirimler)
  • Analitik (dil bazında raporlama)
  • Arama (dil farkındalıklı indeksleme ve eşanlamlılar)

Bir pilot çalışması—birkaç sayfa, bir menü ve meta verilerin uçtan uca çevrilmesi—bir özellik listesi kadar bilgi verir.

Çeviri iş akışı ve içerik yönetişimi oluşturun

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.

Paylaşılan bir stil rehberi oluşturun

Tüm çevirmenlerin ve editörlerin takip edebileceği hafif bir stil rehberiyle başlayın. Pratik tutun:

  • Ton ve üslup: resmi mi yoksa samimi mi, okuyucuya nasıl hitap ediliyor (sen/biz), okuma seviyesi
  • Sözlük: anahtar terimler için onaylanmış çeviriler (program isimleri, özellikler, yasal ifadeler) ve hiç çevrilmemesi gereken kelimeler
  • İsim ve terim kuralları: ürün isimleri, kuruluş adları, yer adları, kısaltmalar, büyük/küçük harf kuralları ve tarih/ sayı formatlama

Bu, aynı kavramın üç farklı çeviriye dönüşmesini azaltır ve arama ile destek işlemlerini kolaylaştırır.

Doğru çeviri yaklaşımını seçin

Çoğu portal karışık bir model kullanır:

  • Profesyonel çeviri kamuya açık sayfalar, yasal içerik ve hassas konular için
  • İç ekip çevirisi iki dilli personel ve konu uzmanlığı olduğunda
  • Makine destekli iş akışları (MT + insan incelemesi) büyük hacimler, düşük riskli güncellemeler ve hızlı teslim için

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.

Net rollerle bir inceleme yolu belirleyin

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.”

Çevirilerin geride kalmasını önleyin

Bir dilin aylarca geride kalması güven kaybettirir. Rutin oluşturun:

  • Güncellemeleri önemli (çevrilmeli) ve önemsiz (bekleyebilir) olarak etiketleyin
  • SLA’lar belirleyin (örn. en önemli sayfalar 48 saat içinde, uzun formatlı içerikler bir hafta içinde)
  • Bir bekleyen liste ve düzenli tempo (haftalık çeviri partisi + aylık denetim) tutun

Tutarlılık kahramanlıklardan daha etkilidir: düzenli kontroller ve net sahiplik, dillerin birbirinden kopmasını engeller.

Tasarım detaylarını yerelleştirin (fontlar, formatlama, RTL)

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.

Dil farklılıkları için alan bırakın

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:

  • Sabit yükseklikli kartlar yerine akıcı bileşenler (otomatik yükseklik, responsive grid) tercih edin
  • Yazının görsellere gömülü olmadığına dikkat edin; etiketlerin doğal olarak yeniden boyutlanabilmesini sağlayın
  • Ana şablonları (anasayfa, makale sayfası, navigasyon, kartlar) uzun örnek metinlerle test edin

Dillerinizi gerçekten destekleyen fontlar seçin

İ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:

  • Tasarım onayından önce glif kapsama alanını doğrulayın
  • Mantıklı yedek fontlar tanımlayın (eksik karakterler □ olarak görünmesin)
  • Bazı alfabelerde font ağırlıkları farklı görünebilir; bunu gözlemleyin

RTL (sağdan sola) desteğini hack olmadan sağlayın

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:

  • Yerleşimin yönünü (padding, margin, ikonlar, ilerleme göstergeleri) çevirebilme
  • RTL için mantıklı ikonlar kullanma (oklar, "ileri/geri" özellikle)
  • Karışık içerik okunabilirliğini koruma (ör. Arapça metin içinde İngilizce ürün kodları)

Yerel formatlama: tarih, sayı ve birimler

Formatlama güvenin bir parçasıdır. Bilgileri kullanıcıların beklediği şekilde gösterin:

  • Tarihler ve saatler (12/24 saat, ay/gün sırası, haftanın başlangıcı)
  • Sayılar (ondalık ayıracı virgül mü nokta mı, binlik ayırıcı)
  • Birimler ve para birimleri (metrik vs. imperial; yerel para gösterimi)

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 temellerini uygulayın (tahmine yer yok)

Çok dilli SEO’yu baştan entegre edin
Koder.ai sayfalarınızı oluştururken yerelleştirilmiş meta verileri ve hreflang’i ayarlayın.

Ç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.

Her dilde sayfa içi temellerle başlayın

Sadece gövde metnini çevirmeyin. Her dil versiyonunun kendi:

  • Sayfa başlığı (title tag) ve meta açıklaması
  • Ana başlıklar (H1/H2) (anlam veya anahtar kelime değişirse)
  • Görsel alt metinleri (özellikle işlevsel görseller için)

Kelime kelime çeviri yerine doğal ifadeler hedefleyin. Kelimesi kelimesine başlık, gösterim oranını olumsuz etkileyebilir.

Eşdeğer sayfaları bağlamak için hreflang kullanın

Google'ın doğru dil versiyonunu göstermesi ve "çoğaltılmış içerik" karışıklığını önlemek için hreflang ekleyin.

Temel kurallar:

  • Eşleşen sayfaları bağlayın (örn. /en/guide ve /es/guide), sadece ana sayfaları değil
  • Hreflang karşılıklı olmalı (EN ES’ye işaret ediyorsa ES de EN’e işaret etmeli)
  • Doğru dil kodlarını kullanın (en, es, fr-CA gibi). Bir global varsayılan için x-default düşünün

Bölge hedefleme konusunda emin değilseniz, dil-oynaklı ayırmadan önce dil-only kullanın.

İnce, otomatik çevrilmiş "doldurma" sayfalarından kaçını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:

  • Anahtar sayfaları önceliklendirin (en üst açılış sayfaları, yüksek niyetli rehberler, S.S.S., kritik politika sayfaları)
  • Dil kapsamasını trafik ve iş hedeflerine göre aşamalı genişletin

Mümkünse dil başına sitemap’lar gönderin

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.

Her dilde gezinme ve aramayı çalışır hale getirin

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.

Arama nasıl davranmalı karar verin

Erken kararlaştırın: site içi arama dil başına mı yoksa çapraz dil mi olacak?

  • Dil başına arama daha basit ve daha az kafa karıştırıcıdır: sonuçlar arayüz diline uyar ve kullanıcıların okuyamayacağı sayfalar gösterilmez
  • Çapraz dil arama seyrek diller veya uzman kullanıcılar için faydalı olabilir, ama iyi etiketleme (örn. "Diğer dillerdeki sonuçlar") ve alaka ayarı gerektirir

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.

"Bu dilde ara"yı varsayılan yapın

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:

  • Arama kutusu yakınında mevcut dili gösterin
  • Çapraz dil sonuç varsa ayrı başlık altında dil etiketli gruplama yapın

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:

  • Kanonik kavram (örn. “Kamu sağlığı”)
  • Her dil için onaylı çeviriler
  • Belirsiz terimler için notlar

Bu, zamanla "Yardım Merkezi"nin "Destek", "Asistanlık" ve "Müşteri Yardım" gibi farklı biçimlere dönüşmesini engeller.

Çok dilli dostu 404 sayfaları ekleyin

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ı:

  • Ziyaretçinin mevcut dilinde görünmek
  • Hedefe yakın kalmalarını sağlayacak bir dil geçişi sunmak
  • Ana bağlantılar (anasayfa, önemli kategoriler, iletişim) ve bir arama kutusu önermek

Popüler sürekli güncel sayfalarınız varsa “En çok ziyaret edilen kaynaklar” gibi önerilerle oturumu hızlıca kurtarın.

Formları, erişilebilirliği ve kilit kullanıcı yolculuklarını yerelleştirin

Portali hızlıca prototipleyin
Yapınızı sohbette tanımlayın ve çok dilli portalı daha hızlı yayınlayı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.

Formlar: sadece etiketleri çevirmekten daha fazlası

Form deneyimini uçtan uca yerelleştirin:

  • Alan etiketleri, placeholder’lar ve yardımcı metin (robot gibi değil, eylem odaklı ifadeler kullanın)
  • Doğrulama ve hata mesajları aynı tonda olsun ve yerel format beklentilerine uyum sağlasın (örn. geçerli telefon numarası istendiğinde yerel biçim dikkate alınmalı)
  • Başarı durumları (onay ekranları, bannerlar, sonraki adımlar) yerel dilde açık olsun

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.

Diller arası erişilebilirlik

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:

  • Kontrast ve okunabilirlik, bazı alfabelerde fontlar daha ince olabilir
  • Klavye gezintisi (tab sırası, görünür odak durumları, diyaloglarda tuzak olmaması)
  • Girdi ve butonlar için açık etiketler; sadece placeholder’a dayanmayın

İkonlar (örn. bilgi tooltip’i) kullanıyorsanız açıklamanın ekran okuyucular için çevrildiğinden emin olun.

Bölgesel yasal ve onay gereksinimleri

Ç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.

Gerçek denetçilerle ana yolculukları test edin

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.

Yayına alın, performansı ölçün ve zaman içinde bakım yapın

Ç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.

Çok dilli bir yayın kontrol listesi ile başlatın

Yeni sayfalar (veya büyük bir yeniden tasarım) yayımlamadan önce tekrarlanabilir bir kontrol listesi kullanın:

  • UI dizeleri çevrildi (gezinme, butonlar, sistem mesajları)
  • Sayfa içeriği çevrildi ve gözden geçirildi (ilgili yerde alt metin dahil)
  • Meta veriler yerelleştirildi (title tag, meta açıklama, open graph alanları)
  • Doğru canonical URL’ler ve dil bildirimleri (kullandığınız yerde hreflang dahil)
  • Dil seçici gerçek eşdeğerlere işaret ediyor (varsayılan anasayfaya değil)

Bunu bir kapı olarak görün: bir dil eksikse ya tamamlayın ya da o dildeki sayfayı kasıtlı olarak gizleyin.

Performansı site genelinden ziyade dil bazında ölçün

Raporlamayı "İspanyolca nasıl gidiyor?" sorusunu cevaplayacak şekilde kurun, sadece "site nasıl gidiyor?" demeyin. Dil bazında izleyin:

  • Trafik trendleri ve edinim kaynakları
  • En iyi sayfalar (ve keşfedilmeyen sayfalar)
  • Dönüşümler ve ayrılma noktaları (bülten kaydı, iletişim, indirme)
  • Yerelleştirilmiş terimler için arama sorguları ve gösterimler

Bu, bir sorunun çeviri kalitesi mi (yüksek çıkış) yoksa keşfedilebilirlik mi (gösterim yok) olduğunu ortaya koyar.

Güncellemeler sonrası eksik çevirileri ve kırık bağlantıları izleyin

Ç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:

  • Eksik çeviri yer tutucuları
  • Dil bazında kırık dahili linkler
  • Tutarsız URL değişikliklerinin oluşturduğu yönlendirme zincirleri

Bakımı rutine sokun

İçeriği ve SEO’yu uyumlu tutmak için üç aylık denetimler planlayın:

  • Her dilde en fazla trafik alan sayfaları doğrulayın
  • Dil versiyonları arasındaki boşlukları karşılaştırın (eksik bölümler, güncellenmemiş ekran görüntüleri, eski politikalar)
  • Büyük içerik itişlerinden sonra hreflang ve indeksleme sağlığını doğrulayı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.

SSS

Çok dilli bir bilgi portalında öncelikle neyi çevirmeliyim?

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:

  • Çevrilmeli (kritik yolculuklar)
  • Çevrilmeli (Önemli) (yüksek trafik alan rehberler/S.S.S.)
  • Tek dilde kalabilir (niş veya dahili güncellemeler)

Bu, "her şeyi çevirelim" harcamalarını önler ve en çok önem taşıyan yerlerde kaliteyi korur.

Çok dilli portal için hangi başarı metriklerini belirlemeliyim?

Sayfa görüntülemelerden öte sonuçlara bağlı metrikler seçin. Yaygın seçenekler:

  • Lokalize sayfalara gelen organik arama trafiği
  • Dil bazında dönüşümler (kayıtlar, indirmeler, form gönderimleri)
  • Önemli rehberlerde etkileşim (sayfada geçirilen süre, kaydırma derinliği)
  • Yanlış anlamalardan kaynaklanan destek taleplerinde azalma

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.

Çoklu diller için bilgi mimarisini nasıl yapılandırmalıyım?

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:

  • Üst düzey bölümlerin sayısını az ve stabil tutun
  • “Diğer” gibi karışık kategorilerden kaçının
  • Büyümeyi mevcut bir bölümün alt seviyesinde planlayın

Tutarlı bir yapı gezinmeyi, aramayı, analitiği ve çeviri iş akışlarını çok daha kolay yönetir.

Kategorileri ve etiketleri diller arasında nasıl tutarlı tutarım?

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ı:

  • Kategoriler diller arasında anlam olarak sabit kalmalı (etiketler farklı olsa da arka plandaki kavram aynı olsun)
  • Kimlerin etiket oluşturabileceğini sınırlayın (etiketler hızla çoğalır)
  • Birleştirme/emekliye ayırma kuralları belirleyin

Bu, farklı sayfalarda benzer bölümlerin farklı, kafa karıştırıcı etiketlere dönüşmesini önler.

Çok dilli içerik için hangi URL yapısı en iyi: alt dizin, alt alan ya da ayrı alanlar?

Çoğu portal için alt dizinler (ör. /en/, /es/) varsayılan öneridir. Avantajları:

  • Tek bir analytics mülkünde izleme
  • Paylaşılan şablonlar ve yönetim kolaylığı
  • Daha düşük operasyonel yük

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.

Çok dilli bir portalda yönlendirmeler ve canonical URL’leri nasıl yönetmeliyim?

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ın
  • Emekliye ayrılan URL’ler için 301 yönlendirmesi kullanın
  • Kaçınılmaz çoğaltmalarda canonical etiketleri kullanın

Ayrı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.

Dil seçiciyi nereye koymalıyım ve otomatik algılama kullanmalı mıyım?

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:

  • Tarayıcı/konum bilgisine göre öneride bulunun
  • Kullanıcıyı hapsetmeyin (zorunlu yönlendirmeler yapmayın)
  • Kullanıcının seçimini bir çerez ve oturum profilinde saklayın

Bu, geçişi öngörülebilir kılar ve kullanıcıyı rahatsız etmez.

Eksik çeviriler UX’i bozmadan nasıl ele alınmalı?

Kullanıcıyı çıkmaza sokmayın. Bir sayfa çevrilmemişse:

  • Kullanıcının seçtiği dilde ara yüzü tutun ve nazikçe çevirinin olmadığını bildirin
  • Açık etiketli bir bağlantı ile varsayılan dildeki versiyona yönlendirin
  • Kategori sayfası, arama sonuçları veya anasayfa gibi alternatifler sunun

Bu, çeviriler hâlâ ilerlerken güveni korur ve geçiş düğmesinin “bozuk” gibi görünmesini engeller.

Birçok dilli portalı yönetmek için CMS’te en çok hangi özellikler önemli?

CMS’inizin dil başına yönetebildiğinden emin olun:

  • Sayfalar ve yeniden kullanılabilir bloklar
  • Menüler ve gezinme etiketleri
  • SEO meta verileri (başlıklar, açıklamalar, paylaşım metinleri)
  • Medya alanları (altyazı, alt metin)

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.

Çok dilli SEO için hangi temel uygulamaları ilk günden uygulamalıyım?

Her dilde sadece gövde metnini değil, şu öğeleri de yerelleştirin:

  • Sayfa başlığı (title tag) ve meta açıklama
  • Ana başlıklar (H1/H2) gerektiğinde
  • İşlevsel resimler için alt metin

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.

Related posts