8 dk

Okullar ve Üniversiteler için Çok Dilli Web Sitesi Nasıl Oluşturulur

Okullar ve üniversiteler için çok dilli bir web sitesini planlamayı, oluşturmayı, çevirmeyi ve sürdürmeyi; temel UX, SEO ve yönetişim ilkelerini öğrenin.

Okullar ve Üniversiteler için Çok Dilli Web Sitesi Nasıl Oluşturulur

Hedefleri, kitleleri ve dil kapsamını belirleyin

Çok dilli bir eğitim sitesi, kimin için hizmet verdiği, onların ne yapması gerektiği ve hangi dillerin gerçek engelleri ortadan kaldırdığı konusunda netlikle başladığında en iyi şekilde çalışır. Araçları seçmeden veya çeviriye başlamadan önce liderlik, kayıt ve iletişim ekiplerini ortak bir plan etrafında hizalayın.

Kilit kitlelerinizi belirleyin

Çoğu okul ve üniversite sitesi aynı anda birden fazla gruba hizmet eder. İçerik önceliklendirmesi yapabilmek için bunları açıkça listeleyin:

  • Mevcut öğrenciler
  • Veliler/vasiler
  • Akademik ve idari personel
  • Mezunlar ve bağışçılar
  • Uluslararası başvuru sahipleri ve değişim öğrencileri
  • Yerel topluluk ortakları

Kurumunuzun farklı kampüsleri, programları veya yaş grupları varsa, ihtiyaçların nerede farklılaştığını not edin (ör. K–12 velileri ile lisansüstü başvuru sahipleri arasındaki farklar).

Ziyaretçilerin tamamlaması gereken ana görevleri tanımlayın

Çok dilli içerik yalnızca "çevirilmiş sayfalar" olmak yerine eylemleri desteklemeli. Her kitle için en önemli görevleri yazın, örneğin:

  • Kabul gereksinimlerini, son tarihleri ve öğrenim ücretlerini bulmak
  • Doğru ofisle hızlıca iletişim kurmak
  • Formları tamamlamak (kayıt, belge talepleri, konaklama)
  • Haberleri ve acil durum duyurularını okumak
  • Takvimleri görüntülemek (akademik tarihler, etkinlikler, kapanışlar)

Bu görevler, hangi içeriğin her dilde doğru ve güncel olması gerektiğine karar vermenize yardımcı olur.

Hangi diller desteklenecek — ve neden — karar verin

Dilleri kayıt hedefleri, başvuru pazarları, topluluk demografisi ve destek istekleri gibi kanıtlara dayanarak seçin. Başlangıçta, yüksek riskli yolculuklarda (başvurular, ödemeler, güvenlik bilgileri) sürtünmeyi azaltacak dillerle başlayın. Kaynaklar sınırlıysa, lansman için "asgari uygulanabilir" bir dil seti ve genişleme yol haritası tanımlayın.

Ölçülebilir başarı metrikleri belirleyin

Sonuçlara bağlı metrikler seçin, örneğin:

  • Tekrarlayan destek taleplerinin azalması (konu ve dil bazında takip edin)
  • Daha nitelikli talepler veya tamamlanan başvuruların artması
  • Önemli sayfalarda daha iyi etkileşim (sayfada kalma süresi, form tamamlama)
  • Kabul ve iletişim sayfalarında hemen çıkma oranının azalması

Bu kararları kısa tek sayfalık bir belgeyle kaydedin, böylece sonraki tüm seçimler (içerik, tasarım, iş akışı) aynı hedefleri destekler.

İçeriği denetleyin ve neyi çevireceğinize karar verin

Çeviri, her şeyi otomatik olarak çevirmek değil, doğru içeriği çevirmekle en etkili olur. Başlamadan önce tam bir envanter oluşturun ki ne olduğunu, neyin eksik olduğunu ve neyin çeviriden önce kaldırılması gerektiğini bilin.

Tam bir içerik envanteri oluşturun

Tüm herkese açık sayfaları ve dosyaları listeleyin; PDF'ler ve ailelerin sıkça güvendiği "gizli" belgeler de dahil: politikalar, el kitapları, kayıt rehberleri, ücret tarifeleri, ulaşım kuralları, korunma beyanları ve erişilebilirlik bilgileri. Metin içeren medyayı (el ilanı resimleri, taranmış formlar) dahil edin çünkü bunlar genellikle sadece çeviri değil yeniden yazma gerektirir.

Basit bir elektronik tablo yeterlidir. URL, sayfa başlığı, sahibi, son güncelleme tarihi ve nerede bulunduğunu (CMS sayfası, PDF, Google Doc) kaydedin.

İçeriği tür ve önceliğe göre etiketleyin

Öğeleri şu şekilde gruplayın:

  • Sürekli (Evergreen): kabul genel bakışı, müfredat, kampüs bilgileri, öğrenim ücretleri, öğrenci desteği, yasal/politika sayfaları.
  • Zamana duyarlı: duyurular, takvimler, etkinlik yayınları, acil durum güncellemeleri, son tarih hatırlatmaları.

Bu, bir haftada sona erecek içeriği çevirmemenizi sağlar ve hangi içeriklerin daha hızlı işlem gerektirdiğini netleştirir.

Hangi içeriğin kesinlikle çevrilmesi gerektiğine karar verin

Her kitle (veliler/vasiler, başvuru sahipleri, mevcut öğrenciler, mezunlar) için içeriği şu şekilde işaretleyin:

  • Gerekli (yanlış anlaşılma halinde yüksek etkili/yüksek risk): kabul adımları, uygunluk, son tarihler, politikalar, iletişim detayları.
  • Önerilen: program öne çıkanları, öğrenci yaşamı, SSS.
  • Tek dilli kabul edilebilir: yüksek uzmanlık gerektiren araştırma haberleri veya arşiv yayınları—bunları açıkça etiketleyerek yalnızca tek dilde bırakabilirsiniz.

Çeviriye başlamadan önce çoğaltmayı kaldırın

Çeviri bakım işini katlar. Yinelenen sayfaları birleştirin, eski içerikleri silin ve terminolojiyi standartlaştırın (program adları, kademe adları, ofis başlıkları) ki çevirileriniz tutarlı kalsın ve güncellemesi kolay olsun.

Çok dilli site yapısını seçin (URL'ler ve navigasyon)

URL yapınız, çok dilli eğitim sitesinin omurgasıdır. SEO'yu, analizleri, düzenleme iş akışlarını ve öğrenciler/veliler için doğru sayfa paylaşımını etkiler.

Üç yaygın URL seçeneği

  • Alt klasörler (Subfolders): example.edu/es/ ve example.edu/fr/
    Tek bir site yönetmek, marka tutarlılığı ve daha basit analizler istiyorsanız en uygunudur.
  • Alt alan adları (Subdomains): es.example.edu
    Ekipler yarı-bağımsızsa işe yarar, ama birden fazla site yönetiyormuşsunuz gibi gelebilir.
  • Ayrı domainler: example.edu ve example.edu.mx (veya farklı TLD'ler)
    Bölgesel esneklik sağlar, ancak yönetişim, SEO ve içerik eşleşmesi açısından en yüksek yükü getirir.

Çoğu okul ve kolej için alt klasörler pratik bir varsayıntıdır: tek bir CMS, tek bir tasarım sistemi, tek bir teknik ayar seti ve daha kolay dil arası gezinme.

Tutarlı URL desenleri planlayın

Öngörülebilir bir desen seçin ve zaman içinde kararlı tutun:

  • Dil kodlarını ilk seviyede kullanın: /es/, /ar/, /zh/.
  • Slug'ları mümkün olduğunca hizalayın: /es/admissions/ ile /en/admissions/ eşleştirilmiş olsun.
  • Hangi öğelerin çevrilmeyeceğine karar verin (çoğunlukla: PDF dosya adları, belirli kısaltmalar, dahili sistem yolları).

Tutarlılık, menüleri, ekmek kırıntılarını ve çeviri iş akışlarını birden fazla departman yayın yaparken kolaylaştırır.

Dil bazlı navigasyon ve ekmek kırıntıları

Navigasyon çevirilmiş ve kültürel olarak anlaşılır olmalı, sadece kopyalanmış olmamalı. Şunları oluşturun:

  • Her dil için ana menü (bazı öğeler farklı olabilir)
  • Dil bazlı ekmek kırıntıları (kullanıcıların nerede olduklarını görmeleri için)
  • Varsa karşılığı olan dil sayfalarına işaret eden çapraz bağlantılar

Her dilde olmayan sayfalarla başa çıkma

Kurumlar genellikle bazı programları, kampüsleri veya formları yalnızca tek bir dilde sunar. Baştan karar verin:

  • O dilin navigasyonundan mevcut olmayan sayfaları gizleyip gizlememe
  • "Bu dilde mevcut değil" kısa bir sayfa gösterip net sonraki adımlar sunma
  • Kullanıcıları en yakın alternatife nasıl yönlendireceğiniz (ör. İngilizce program genel bakışına bağlantı)

Bu, eksik sayfa sonlarını ve ziyaretçilerin tamamlanmamış bir siteyle karşılaştığı hissini önler.

Bir CMS seçin ve yayın iş akışlarını tanımlayın

Çok dilli bir eğitim sitesi günlük operasyonlarda başarılı olur ya da başarısız olur. Doğru CMS, dil versiyonları oluşturmayı, bunları doğru kişilere yönlendirmeyi ve tutarlı şekilde yayımlamayı kolaylaştırmalıdır—her şeyi tek bir "web kişisine" bağlamadan.

CMS'de aramanız gerekenler

Yerel (veya iyi desteklenen modüllerle) çok dilli sayfa ve içerik tiplerini destekleyen bir CMS seçin. Taahhüt etmeden önce doğrulamanız gereken temel yetenekler:

  • Dil farkındalığı olan sayfa yönetimi: her sayfa bağlı çevirilere sahip olabilir ve "eksik çeviri" durumu açıkça görülür.
  • Roller ve izinler: okullar, bölümler ve merkezi iletişim için ayrı erişim.
  • İş akışı durumları: taslak → çeviride → incelemede → onaylandı → zamanlanmış/yayınlandı.
  • Sürüm geçmişi ve yorumlar: çevirmenler ve inceleyiciler anlamı netleştirebilsin.
  • Her dil için meta veri: başlıklar, açıklamalar ve sosyal önizlemeler her yerel dil için düzenlenebilir olmalı.

Kurumunuz zaten bir CMS kullanıyorsa, önce küçük bir sayfa kümesi üzerinde çok dilli yayımlamayı test edin (ör. kabul ve iletişim) ki eksikleri görün.

Yeni deneyimler de oluşturuyorsanız (uluslararası başvuru sahipleri için bir microsite, burs portalı veya çok dilli etkinlik merkezi), önce CMS dışında prototiplemeyi düşünün. Örneğin, Koder.ai ekiplerin sohbet tabanlı bir spesifikasyondan çalışan bir web uygulaması üretmelerine yardımcı olabilir—sayfa şablonlarını, dil değiştirme davranışını ve iş akışlarını doğrulamak için kullanışlıdır. Koder.ai kaynak kodu dışa aktarabildiği ve dağıtım/barındırma artı anlık görüntü ve geri alma desteklediği için hem erken prototipleme hem üretime aktarım aşamalarına uyabilir.

Roller tanımlayın (ve kim neyi sahiplenir)

Erken beklentileri netleştirin; örneğin:

  • Editör: kaynak dil içeriğini yazar ve yönetir.
  • Çevirmen: çevrilmiş versiyonu üretir (iç ekip ya da tedarikçi).
  • İnceleyici: terminoloji, ton ve doğruluğu doğrular (genellikle uluslararası ofis veya iki dilli personel).
  • Yayımlayıcı: biçimlendirme, bağlantılar ve uyumluluk açısından son kontrolü yapar.

Sahipliği net tutun: bölümler program detaylarını güncelleyebilir; merkezi ekip global navigasyon, politika sayfaları ve marka sesinden sorumlu olsun.

Ana sayfalar için şablonlar planlayın

Çevirilerin öngörülebilir kalması için şablonları standartlaştırın:

  • Kabul (gereksinimler, son tarihler, öğrenim/vize rehberi)
  • Programlar ve bölümler (genel bakış, öğrenme çıktılarına göre, iletişim)
  • İletişim ve kampüs bilgileri (adresler, haritalar, ofis saatleri)

Şablonlar yeniden işi azaltır ve inceleyicilerin anlam üzerinde odaklanmasını sağlar.

Medya ve her dil için alt metinleri unutmayın

Medya kütüphaneniz her dil için alt metin (ve ideal olarak video için altyazı/transkript) desteklemelidir. Alt metin genellikle çeviri gerektirir çünkü anlam iletir ve erişilebilirliği destekler—özellikle formlar, infografikler ve öğretici görseller için.

Dil değiştirme ve navigasyon için UX tasarımı

Ziyaretçiler diller arasında hızla geçiş yapıp yönlerini koruduklarında çok dilli bir okul veya üniversite sitesi başarılı olur. Uluslararası öğrenciler, veliler ve akademisyenler genellikle derin bağlantılarla gelir (bir program sayfası, bir son tarih duyurusu), bu yüzden dil deneyimi anasayfanın ötesinde de çalışmalı.

Dil seçiciyi insanların beklediği yerde konumlandırın

Dil seçiciyi tüm şablonlarda tutarlı, bulunması kolay bir yere koyun—genellikle başlık kısmında (LTR diller için sağda). Mobilde de görünür olmalı (başlıkta veya menü içinde ilk öğelerden biri). Footer'a gömülmemeli.

Açık dil etiketleri kullanın (sadece bayrak değil)

Dilleri kendi yerel adlarıyla etiketleyin—"English", "Español", "العربية"—sadece bayrak kullanmayın. Bayraklar belirsiz olabilir (ör. İspanyolca farklı ülkelerde farklılık gösterir) ve birçok kullanıcı dilini tek bir bayrakla ilişkilendirmez.

Her dilde navigasyon okunaklı olsun

Menülerde kısaltmalardan kaçının ("Acad.", "Intl.") çünkü bunlar çeviriye uygun düşmez. "Admissions", "Programs", "Student Life" gibi kısa, sade terimler kullanın. Çeviri sonrası metin uzuyorsa, metnin küçülmesine izin vermek yerine düzenin uygun şekilde sarılmasına izin verin.

Sağdan sola (RTL) diller için plan yapın

Arapça, İbranice veya benzer bir dil destekliyorsanız baştan RTL için tasarlayın: ayna düzenleri, uygun tipografi, ikon ve ok hizalaması ve formların doğal davranışı. Kabul, bilgi talebi, başvuru gibi ana sayfaları erken test edin.

Eksik çeviriler için geri dönüş davranışını tanımlayın

Bir sayfanın henüz çevrilmediği durumda ne olacağını kararlaştırın. Yaygın yaklaşımlar:

  • Sayfayı varsayılan dilde gösterin ve kısa bir not ekleyin (ve çevrilmiş bölüme geri bağlantı verin).
  • En yakın çevrilmiş üst sayfaya yönlendirin (ör. bölüm genel bakışı).

Hangi yöntemi seçerseniz seçin, kullanıcıları bilgilendirin—sessiz yönlendirmeler siteyi "bozuk" hissettirebilir.

Çeviri ve inceleme süreci oluşturun

Extend to Mobile Apps
Öğrenciler ve veliler için Flutter ile tamamlayıcı mobil deneyimler oluşturun.

Çok dilli bir site güven üzerine kuruludur. Okullar ve üniversiteler için ailelerin okuduklarına güvenebilmesi gerekir—özellikle konu kabul, güvenlik, politikalar ve öğrenci desteği ise.

Hangi içeriklerin insan tarafından çevrileceğine karar verin

İçeriği risk ve etkiye göre sınıflandırın. Aşağıdaki kritik sayfalar için insan çevirisi kullanın:

  • Kabul ve başvuru adımları
  • Öğrenim ücretleri, ücretler ve geri ödemeler
  • Yasal bildirimler, gizlilik ve onay formları
  • Sağlık, güvenlik ve acil durum bilgileri
  • Erişilebilirlik beyanları ve zorunlu açıklamalar

Daha düşük riskli içerikler için daha hızlı yaklaşımlar kullanılabilir—ama yine de inceleme ve açık sahiplik şart.

Tutarlılık için bir sözlük + çeviri belleği oluşturun

Eğitim siteleri özel terimleri tekrarlar: program adları, kampüs yerleri, kademe adları, burs isimleri ve politika ifadeleri. Oluşturun:

  • Tercih edilen çevirilerden oluşan bir sözlük (marka adları gibi "çevirme" öğeleri dahil)
  • Onaylanmış cümleleri yeniden kullanmak için çeviri belleği

Bu, aynı programın sayfalar arasında farklı şekilde çevrilmesini engeller.

Rolleri ve inceleme kapılarını netleştirin

Güncellemelerin tıkanmaması için hafif bir iş akışı tanımlayın:

  1. İçerik sahibi (bölüm) kaynak içeriği yazar veya günceller
  2. Çevirmen sözlük ve çeviri belleğini kullanarak çeviriyi yapar
  3. İki dilli inceleyici anlam, ton ve kurumsal doğruluğu kontrol eder
  4. Nihai onaylayıcı yasal/politika sayfalarını yayımlamadan önce doğrular

Hizmet düzeyi beklentileri ekleyin (ör. "kabul sayfaları 3 iş günü içinde güncellenir") ki dil versiyonları geride kalmasın.

Makine çevirisi kullanıyorsanız bunu açıklayın

Makine çevirisi kritik olmayan içerikte yardımcı olabilir, ama önemli sayfalarda makine çıktısını insan onayı olmadan yayımlamayın. Kullanıyorsanız bunu açıkça etiketleyin ve sorun bildirme yolu sağlayın (ör. footer'da kısa bir not ve geri bildirim formu).

Bu süreci basit bir dahili sayfada belgeleyin (ör. /blog/translation-workflow) ki yeni personel aynı adımları takip edebilsin.

Çok dilli SEO'yu yönetin (hreflang, metadata, indeksleme)

Çok dilli SEO, ailelerin ve başvuru sahiplerinin Google'dan doğru dil sürümünü bulmasına yardımcı olur—çoğaltmaları, karışık dilleri veya yanlış kampüs bilgilerini önler. Amaç belliktir: bir konu, birden fazla dil sürümü; her biri arama motorlarına net şekilde etiketlenmiş.

Benzersiz URL'ler ve tutarlı desenler kullanın

Her dil için kararlı bir URL verin. Yaygın seçenekler:

  • Alt klasörler: /en/admissions/ ve /es/admisiones/ (genellikle yönetmesi en kolay)
  • Alt alan adları: en.example ve es.example

Hangi yöntemi seçerseniz seçin, her dil içinde navigasyon ve dahili bağlantıları tutarlı tutun ki arama motorları ve kullanıcılar diller arasında rastgele geçiş yapmasın.

Başlıkları ve meta açıklamaları her dil için yazın

Her dil sürümü için benzersiz sayfa başlığı ve meta açıklama oluşturun—çeviri yapılmış sayfalarda İngilizce meta bırakmayın. İnsanların o dilde nasıl arama yaptığını dikkate alarak doğal ifadeler kullanın (özellikle Kabul, Öğrenim Ücretleri, Programlar ve İletişim gibi niyet ağırlıklı sayfalar).

Sayfa içindeki önemli başlıkları (H1/H2) da doğal şekilde çevirin. Anahtar kelime doldurmaktan kaçının; özellikle okullar için güvenilirliği zedeler.

hreflang ve doğru kanonik etiketleri uygulayın

hreflang ile arama motorlarına her sayfanın hangi dili (ve isteğe bağlı bölgeyi) hedeflediğini ve diller arası ilişkisini söyleyin; bunu doğru kanonik etiketlerle eşleştirin ki Google çevirileri çoğaltma olarak görmesin.

Basitleştirilmiş bir örnek (İngilizce sayfada) şöyle görünür:

\u003clink rel=\"alternate\" hreflang=\"en\" href=\"/en/admissions/\" /\u003e
\u003clink rel=\"alternate\" hreflang=\"es\" href=\"/es/admisiones/\" /\u003e
\u003clink rel=\"alternate\" hreflang=\"x-default\" href=\"/admissions/\" /\u003e

Her dil sayfası kendi kendine ve muadilleriyle referans vermelidir.

İndeksleme ve sitemap: arama motorlarının doğru sayfaları bulmasına yardımcı olun

Kurulumunuz gerekiyorsa çok dilli sitemap'ler oluşturun (tek bir sitemap içinde dil URL'leri veya dil başına ayrı sitemap'ler). Bunları Google Search Console'a gönderin.

Kısmi çevrilmiş bölümler için, sayfa tamamlanana kadar noindex kullanmayı düşünün—bu, yarım kalmış çevirilerin indekslenip paylaşılmasını önler. Lansmandan sonra indekslemeyi izleyin ve "dil uyumsuzluğu" sorunlarını kontrol edin; anahtar sayfaları her dilde arayıp kontrol edin.

Çok dilli sitelerde erişilebilirlik ve uyumluluk

Share a Live Demo
Paydaşların mockup değil gerçek sayfaları inceleyebilmesi için prototipinizi dağıtın ve barındırın.

Erişilebilirlik eğitim siteleri için "olmazsa olmaz"dır—öğrenciler, veliler, akademisyenler ve başvuru sahipleri her gün yardımcı teknolojiye güvenir. Birden fazla dil eklediğinizde, erişilebilirlik sorunlarının saklanabileceği yerlerin sayısı da artar.

Önce erişilebilir şablonlar oluşturun

Çekirdek düzenlerin WCAG 2.2 AA gibi yaygın standartlara uyduğundan başlayın (ABD'de ADA/Section 508, AB'de EN 301 549 referans verilir). Her dilde etkili olan temellere odaklanın:

  • Ekran okuyucuların anlayabilmesi için net başlık yapısı (H1–H3)
  • Yeterli renk kontrastı ve okunabilir yazı boyutları
  • Menüler, butonlar, modal pencereler ve dil seçici için tam klavye gezinimi
  • Sadece gerektiğinde ARIA kullanımı (ve yalnızca anlaşılırlık arttırıyorsa)

Belgeleri ve medyayı her dilde erişilebilir yapın

Okullar sıkça PDF olarak temel bilgiler yayınlar. Mümkünse taranmış PDF'lerden kaçının; yardımcı teknolojiyle okunması zordur. Gerçek metin, başlıklar, listeler ve tablo başlıkları olan düzgün yapılandırılmış belgeler sağlayın; dosya adları ve bağlantı metinleri açıklayıcı olsun.

Ses/video için altyazılar ve gerekirse transkript sağlayın—bunları da çevirin.

Erişilebilirlik öğelerini yerelleştirin (sadece ana metin değil)

Erişilebilirlik öğeleri de aynı özenle çevrilmelidir:

  • Görseller için alt metin (süsleyici resimler boş alt ile atlanmalı)
  • Form etiketleri, yardım metinleri ve hata mesajları
  • "İçeriğe atla" metni, ARIA etiketleri (kullanılıyorsa) ve buton isimleri

Ayrıca sayfa dilini ve sayfa içindeki dil değişikliklerini doğru ayarlayın ki ekran okuyucular metni doğru şekilde seslendirsin.

Gerçek koşullarda test edin

Her dili hem mobil hem masaüstünde kontrol edin. Sadece klavye ile gezinmeyi test edin ve en az bir ekran okuyucu ile doğrulama yapın (ör. Windows'ta NVDA/JAWS, iOS/macOS'ta VoiceOver). Metin uzunluğundaki küçük farklılıklar düzenleri bozabilir—bunları lansmandan önce yakalayın.

Ana bileşenler: sayfalar, formlar, takvimler ve entegrasyonlar

Çok dilli bir okul veya üniversite sitesi, "hareketli parçalar" çeviri için baştan tasarlandığında daha kolay yönetilir. Bölümlerin yeniden kullanabileceği standart bileşenlere odaklanın ve zaman duyarlı içeriklerin (uyarılar, etkinlikler, duyurular) her dilde hızlıca yayımlanabilmesini sağlayın.

Bölümler için yeniden kullanılabilir sayfa şablonları

Çoğu ihtiyacı karşılayan küçük bir şablon seti oluşturun—bölüm anasayfası, program detay, personel profili, haber yazısı ve SSS. Düzen öğelerini (başlıklar, etiketler, butonlar, çağrı kutuları) görüntülere gömülü tutmayın; düzenlenebilir alanlarda bırakın.

Pratik bir yaklaşım, her bölümün kullanacağı ortak bir bileşen kütüphanesi tanımlamaktır:

  • Süre, kampüs, gereksinimler gibi tutarlı alanlara sahip program kartları
  • İletişim blokları (telefon, e-posta, ofis saatleri)
  • Çevirilebilir etiketlere sahip CTA butonları (Apply, Request info)

Bu, çeviri iş yükünü azaltır ve tek seferlik sayfaların tutarsızlıklarını önler.

Takvimler, duyurular ve acil uyarılar

Takvimler ve uyarılar sık değiştiği için çok dilli olarak senkronize tutmak en zordur.

Bu öğeleri yapılandırılmış yapın: başlık, kısa özet, detaylar, konum, hedef kitle ve "yayınlanma süresi" alanı. Kritik bilgileri PDF veya resim içinde gömülü bırakmayın. Hızlı güncelleme gerektiğinde "öncelikli dil önce" iş akışını destekleyin ve açık durum göstergeleri (ör. "Çeviri yapılıyor") gösterin ki kullanıcılar yanlış yönlendirilmesin.

Formlar: etiketler, onaylar ve e-postalar

Erken karar verin hangi öğelerin çevrileceğine:

  • Sayfa üzerindeki alanlar ve yardım metinleri
  • Başarı/hata mesajları
  • Onay e-postaları ve personel bildirimleri

Ayrıca gönderimleri nasıl saklayacağınızı planlayın: kullanıcılar farklı dillerde yanıt verirse personel tutarlı bir iç format veya işaretli "gönderim dili" alanına ihtiyaç duyabilir.

Entegrasyonlar ve üçüncü taraf widget'lar

Öğrenci portalları, ödeme sağlayıcıları, kampüs haritaları ve gömülü tedarikçi widget'lar gibi yaygın entegrasyonlar her dili desteklemeyebilir.

Bunları envanterleyin ve hangi öğelerin yerelleştirilebildiğini doğrulayın (UI metinleri, e-postalar, fişler, hata durumları). Bir widget çeviriyi desteklemiyorsa, sayfada net bir alternatif yol sağlayın (ör. çevrilmiş bir iletişim yöntemi veya çevrilmiş portal giriş sayfasına bağlantı).

Analitik, izleme ve sürekli iyileştirme

Çok dilli bir eğitim sitesi lansmandan sonra bitmiş sayılmaz. Diller, programlar ve uluslararası kitlelerin davranışı zaman içinde değişir. Basit bir izleme rutini sorunları erken yakalamanıza ve her dili güvenilir tutmanıza yardımcı olur.

Her dilin nasıl kullanıldığını izleyin

İlk olarak performansı yerel (dil + bölge gerektiğinde) olarak ayırın. Şunlara bakın:

  • Bölge/dil bazında ziyaretler ve cihaz türü (ülkelere göre mobil davranış farklı olabilir)
  • Her dilde en popüler sayfalar (kabul, programlar, öğrenim, konaklama)
  • Site araması ve Google Search Console'da dil bazlı arama terimleri

Bu veriler nerelere yatırım yapacağınızı gösterir. Örneğin, İspanyolca ziyaretçiler çoğunlukla kabul sayfalarına geliyorsa, bu sayfaları güncel ve tam çevirilmiş tutmaya öncelik verin.

Kaliteyi izleyin: eksik içerik ve kırık yollar

Çok dilli siteler sessizce uyumsuz hale gelebilir. Düzenli kontroller kurun:

  • Dil bazında kırık bağlantıları tespit edin (özellikle navigasyon ve footer'da)
  • Bir dilde olan ama diğerinde olmayan sayfaları işaretleyin
  • Ana UI öğelerinde (butonlar, form etiketleri, hata mesajları) eksik çevirileri belirleyin

CMS destekliyorsa, bölüm bazında "çeviri tamlığı" panosu veya zamanlı rapor oluşturun.

Kritik sayfaları güncel tutun

Kabul, program açıklamaları, öğrenim/ücretler, son tarihler ve burs sayfaları gibi yüksek öncelikli sayfalar için bir tazelik takvimi oluşturun. Akademik takvimle bağlayın ki değişiklikler her dilde bir inceleme tetiklesin.

Basit bir geri bildirim döngüsü ekleyin

Çeviri hatası bildirmek için görünür bir seçenek ekleyin (ör. çevrilmiş sayfaların footer'ında). Gönderimler çeviri QA ekibine yönlendirilsin ve sayfa + dil otomatik etiketlensin.

Zamanla bu sinyaller çeviri iş akışınızı iyileştirmenize, destek e-postalarını azaltmanıza ve büyük yeniden tasarımlara gerek kalmadan çok dilli SEO'yu geliştirmenize yardımcı olur. İlgili kurulum adımları için görün: /blog/multilingual-seo-hreflang-metadata ve /blog/translation-review-workflow.

Lansman planı ve aşamalı yayılım

Build Key Page Templates
Dil fark etmeksizin tutarlı kalan kabul, ücret ve iletişim şablonları oluşturun.

Çok dilli bir lansman, bunu tek bir "büyük patlama" olarak görmek yerine küçük, ölçülebilir sürümlere bölmek daha kolay ve güvenlidir. Amaç, aileler ve başvuru sahipleri için hızlıca işe yarar bir şey sunmak ve sonra güvenle genişletmektir.

En yüksek etki yaratan sayfalarla başlayın

En yaygın soruları yanıtlayan ve başvuruları tetikleyen sayfalarla başlayın. Çoğu okul ve kolej için bu şunları içerir:

  • Ana sayfa (programlar genel bakışı ve ana çağrılar)
  • Kabul (/admissions)
  • Öğrenim ve ücretler
  • İletişim bilgileri (ofis saatleri dahil)
  • SSS

Bu ilk set yeni dilde eksiksiz ve güvenilir hissettirmeli: doğru tarihler, telefon numaraları, adresler ve bağlantılar—sadece çevrilmiş paragraflar değil.

Pilot çalışması yapın

Bir ek dil seçin ve pilot olarak yayınlayın. Bu, çeviri, inceleme, yayınlama ve güncellemeyi test etmenizi sağlar—çok sayıda dille uğraşmadan.

Pilot sırasında gerçek kullanıcıları etkileyen pratik sorunları gözleyin:

  • Ziyaretçiler dil seçiciyi kolayca bulabiliyor mu?
  • Ana görevler (bilgi talebi, tur rezervasyonu, başvuru) uçtan uca anlaşılır mı?
  • Kaynak dil değiştiğinde çevrilmiş sayfalar senkron kalıyor mu?

Çeviri backlog'u ve yayın takvimi oluşturun

Çevirilecek sayfaların bir backlog'unu ve bunları yayınlama partileri halinde çıkarma programını oluşturun. Haftalık veya iki haftalık gibi basit bir tempo ilerleme sağlar ve inceleyicilerin işini kolaylaştırır.

İyi bir parti "işi tamamlar"—"belli bir bölümü tamamlamak" değil. Örneğin, "Başvur" için gereken her şeyi çevirin: program sayfası, gereksinimler, son tarihler, onay mesajları ve e-posta şablonları.

Yayına almadan önce kabul kontrolleri tanımlayın

Her parti yayına alınmadan önce şu hızlı kabul kontrollerini yapın:

  • Bağlantılar: dahili bağlantılar çalışıyor ve doğru dil versiyonuna gidiyor
  • Düzen: bozuk boşluklar, hizalanmamış kartlar veya üst üste binmiş metin yok
  • Yazı/karakterler: aksanlar ve özel karakterler doğru görüntüleniyor
  • Metin incelemesi: ton, terminoloji ve resmi isimler doğrulanmış

Aşamalı yayılım riski düşürür ve pilot dilden tam desteklenen çok dilli siteye geçiş için net bir yol yaratır.

Uzun vadeli yönetişim ve içerik yönergeleri

Çok dilli bir eğitim sitesi yalnızca tutarlı kalırsa faydalıdır. "Çeviri sürüklenmesi"ni (sayfaların yavaşça diller arasında farklılaşması) önlemenin en iyi zamanı bir sonraki güncelleme döngüsünden önce değildir—önceden hazırlık yapmaktır.

Editoryal yönergeler: ses, ton ve terminoloji

Katkıda bulunan herkesin (personel yazarları, öğrenci yardımcıları, dış çevirmenler) uyması için kısa bir stil rehberi yazın.

Şunları ekleyin:

  • Ton ve resmiyet kuralları (ör. samimi ama resmi; argo kullanmaktan kaçının; kısaltmaları açıklayın)
  • Tercih edilen terimler: kabul adımları, derece türleri, öğrenci hizmetleri
  • İsim kuralları: ne zaman çevrilir ne zaman resmi ad korunur (ör. "Office of the Registrar" resmi isim olarak korunabilir)
  • Biçim standartları: tarih, telefon numarası, adres, para birimi, saat dilimleri ve büyük-küçük harf kullanımı

Kısa ve uygulanabilir tutun; rehberi editörlerin ve çevirmenlerin gerçekten göreceği bir yerde saklayın (genellikle CMS içinde veya paylaşılan sürücüde).

Programlar, bölümler ve yer adları için paylaşılan sözlük

Aşağıları içeren bir ortak sözlük tutun:

  • Resmi program adları, derece isimleri, ders kodları ve bölüm başlıkları
  • Kampüs ve bina adları, şehir isimleri ve kısaltmalar
  • Onaylanmış çeviriler veya "çevirme" etiketi

Bir sahip atayın (genellikle Pazarlama/İletişim) ve basit bir değişiklik süreci belirleyin: talepler gelir, güncellemeler incelenir ve sözlük çevirmenlere ve içerik editörlerine yayınlanır.

Sahiplik ve değişiklik tetikleyicileri (kim neyi günceller)

"Herkes her şeyi düzenleyebilir" modelinde yönetişim başarısız olur. İçerik sahipliğini bölüm bazında tanımlayın:

  • Kabul, giriş gereksinimleri ve son tarihlerden sorumlu
  • Akademik bölümler program sayfalarından sorumlu
  • Öğrenci hizmetleri destek sayfalarından sorumlu
  • IT/Web ekibi şablonlar, navigasyon ve teknik SEO öğelerinden sorumlu

Sonra çeviri tetikleyicileri tanımlayın ki güncellemeler kaçmasın. Örneğin:

  • Kaynak dil sayfasında her değişiklik otomatik olarak "çeviri inceleme gerektiriyor" görevi oluşturur
  • Son tarihle ilgili sayfalar belirli periyotlarda (ör. kayıt sezonunda aylık) gözden geçirilir
  • Acil durum notları hemen yayınlanabilir; açık bir banner: "Çeviri yapılıyor" gösterilir

Sürecin devam etmesini sağlayacak dokümantasyon

Nasıl yayınlandığını anlatan hafif bir oyun kitabı oluşturun: sayfa tipleri, onay adımları ve irtibat kişileri.

Araçları değerlendirirken, elden ele geçişleri azaltan ve geri almayı güvenli kılan sistemleri önceliklendirin. Örneğin, Koder.ai ile özel çok dilli özellikler geliştiren ekipler sıklıkla planlama modunu kullanıp roller/iş akışını baştan haritalandırır, sonra birçok şablonda gezinme veya dil yönlendirmesi değişiklikleri yaparken anlık görüntüler ve geri alma ile güvenli dağıtım sağlar.

Ara sıra /pricing sayfasını değerlendirmek veya ilgili iş akışı ipuçlarına /blog'dan bakmak faydalı olabilir.

SSS

Eğitim web sitemiz hangi dilleri desteklemeli?

İlk olarak kilit kitlelerinizi (öğrenciler, veliler/vasiler, başvuru sahipleri, akademik/personel, mezunlar) ve tamamlamaları gereken ana görevleri (başvurmak, öğrenim ücretini ödemek, son tarihleri bulmak, ofislerle iletişim kurmak) listeleyin. Ardından dilleri kanıta dayalı seçin—kayıt hedefleri, başvuru pazarları ve toplum demografisi gibi—"iyi olur" taleplere göre değil.

Kitleleri, öncelikli görevleri, desteklenen dilleri ve başarı ölçütlerini belgeleyen tek sayfalık bir özet, departmanlar arası kararlarda tutarlılığı korur.

Çok dilli bir okul veya üniversite sitesi için önce hangi sayfaları çevirmeliyiz?

Yüksek riskli ve yüksek etkili işlemleri destekleyen içeriği önce çevirin:

  • Kabul adımları, uygunluk, son tarihler, öğrenim/ücret bilgileri
  • İletişim bilgileri ve çalışma saatleri
  • Politikalar, güvenlik/acil durum bilgileri, erişilebilirlik beyanları
  • Temel formlar ve onay mesajları

Kısa ömürlü içerikleri varsayılan olarak çevirmemeye çalışın (ör. etkinlik özetleri)—ancak bunlar öncelikli bir görevle ilişkiliyse istisna yapın.

Hangi içerikleri çevireceğimizi (ve hangilerini çevirmeyeceğimizi) seçmek için sitemizi nasıl denetleriz?

Bir içerik envanteri oluşturun (sayfalar, PDF'ler, formlar, "gizli" belgeler) ve her öğeyi sürekli (evergreen) veya zaman duyarlı (time-sensitive) olarak etiketleyin. Ardından her öğeyi Gerekli, Önerilen veya Tek dilli kabul edilebilir olarak işaretleyin.

Çeviriden önce kopyaları kaldırın ve terminolojiyi standartlaştırın (program adları, ofis başlıkları). Çeviri bakım işini çoğaltır, bu yüzden temizlik uzun vadede zaman kazandırır.

Farklı diller için alt klasör, alt alan adı yoksa ayrı domain mi kullanmalıyız?

Çoğu kurum için alt klasörler pratik varsayılandır (ör. /en/, /es/)—bir CMS, tek tasarım sistemi ve daha basit analizler sağlar.

Alt alan adları (subdomain) ekipler bağımsızsa işe yarayabilir ve ayrı domainler en yüksek yönetim, SEO ve içerik eşleşmesi yükünü getirir. Bir model seçin ve zaman içinde tutarlı kalın.

Dil seçiciyi nasıl tasarlamalıyız ve eksik çevirilerle nasıl baş etmeliyiz?

Üst bilgi (header) gibi tutarlı ve kolay bulunur bir yere dil seçiciyi koyun (soldan sağa dillerde sağ taraf tipik). Mobilde de görünür olsun; footer'a gömülü olmasın.

Dillerin yerel adlarını kullanın—"English", "Español", "العربية"—sadece bayrak kullanmayın. Bayraklar kafa karıştırıcı olabilir.

Eksik çeviriler için net bir geri dönüş davranışı belirleyin: varsayılan dili gösterme ve kısa bir not, veya en yakın çevrilmiş üst sayfaya yönlendirme. Sessiz yönlendirmeler kullanıcıyı kaybolmuş hissettirebilir.

Çok dilli yayımlama için hangi CMS özellikleri ve iş akışları önemlidir?

Çevirileri birbirine bağlayabilen, her dil için meta veriyi düzenlemeye izin veren, roller/izinler ve yayın iş akışı durumları (taslak → çeviri → inceleme → yayın) sunan bir CMS seçin. Roller belirleyin ki işler tek bir kişiye takılmasın:

  • Editör (kaynak içeriği yazar)
  • Çevirmen
  • İki dilli inceleyici
  • Yayıncı/onaylayıcı

Kabul, program ve iletişim gibi ana sayfalar için şablonlar kullanın; bu çevirileri tutarlı ve QA'ya uygun kılar.

İnsan çevirisi mi yoksa makine çevirisi mi kullanmalıyız?

Kritik, yüksek riskli içerikler (kabul, ücret/geri ödeme politikası, yasal/gizlilik, güvenlik/acil durum, erişilebilirlik) için insan çevirisini tercih edin. Düşük riskli içerikler (haberler, etkinlik özetleri) için daha hızlı yaklaşımlar kullanılabilir—ancak yine de inceleme ve sahiplik olmalı.

Makine çevirisi kullanıyorsanız bunu açıkça belirtin ve sorun bildirmek için yol sağlayın.

Terminolojiyi diller ve bölümler arasında nasıl tutarlı tutarız?

Terim tutarlılığı için bir tercih edilen çeviri sözlüğü (glossary) ve çeviri belleği (translation memory) oluşturun. Bu, onaylanmış cümlelerin yeniden kullanılmasını sağlar ve maliyet ile süreyi azaltır.

Aksi takdirde aynı program adı farklı sayfalarda farklı biçimlerde çevrilebilir ve okuyucuyu karıştırır.

Eğitim sitesi için çok dilli SEO'nun temel unsurları nelerdir?

Her dil için benzersiz bir URL verin ve hreflang ile doğru kanonik etiketlerini uygulayın ki arama motorları dilleri ayırt edebilsin. Ayrıca meta verileri yerelleştirin:

  • Her dil için sayfa başlıkları ve meta açıklamalar
  • Doğal yazılmış H1/H2 başlıkları

Çok dilli sitemap'leri Google Search Console'a gönderin ve eksik çevirileri indekslemeden önce noindex düşünün.

Çok dilli sitelerde hangi erişilebilirlik gereksinimlerini planlamalıyız?

Çekirdek düzenlerin WCAG 2.2 AA gibi standartlarla uyumlu olmasını sağlayın: başlık yapısı, kontrast, klavye gezinimi, ARIA gerektiğinde. Belgeler ve medyanın da erişilebilir olmasına dikkat edin: taranmış PDF'lerden kaçının, başlık ve tablolar düzgün yapılandırılmış metin içersin.

Erişilebilirlik ögelerini de çevirin: alt metinler, form etiketleri, yardım metinleri ve hata mesajları. Sayfa dilini doğru ayarlayın ki ekran okuyucular doğru telaffuz etsin.

Her dili mobil/masaüstünde ve en az bir ekran okuyucuyla test edin.

Related posts