Statik ve Dinamik Web Sitesi Yerelleştirmesi Arasındaki Fark

Bir siteyi çevirmeye başlamadan önce teknik bir soruya cevap vermek gerekir: bu site, ekranda gördüğünüz metni nereden alıyor? Cevap yalnızca geliştiricileri ilgilendirmez. Metnin nerede durduğu, hangi araçla çıkarılacağını, sürece kaç kişinin gireceğini ve altı ay sonraki güncellemelerin nasıl yönetileceğini doğrudan belirler.

İçindekiler

Statik ve dinamik web sitesi ayrımı, web yerelleştirmesinde karmaşıklığı belirleyen iki temel ayrımdan biridir; diğeri ön yüz ile arka yüz ayrımıdır (Jiménez-Crespo 2024, s. 176-177). Statik sitede sunucuda saklanan yapı, tarayıcıda görünen yapıyla hemen hemen aynıdır. Dinamik sitede ise sayfa, istek geldiği anda bir veritabanından derlenir.

Aşağıda iki yapının nasıl çalıştığını, çeviri akışını nasıl değiştirdiğini ve teklif alırken hangi soruları sormanız gerektiğini anlatıyoruz. Amaç kod öğretmek değil; çeviri satın alan tarafın doğru soruyu sorabilmesini sağlamak.

Statik web sitesi nasıl çalışır?

Statik siteler, WWW’nin ilk dönemindeki mantığı taşır. Her sayfa sunucuda ayrı bir HTML dosyası olarak durur; kullanıcı adresi çağırdığında bu dosya olduğu gibi gönderilir. İçerik sık değişmiyorsa yapı hızlı ve öngörülebilirdir. Yerelleştirme açısından en belirgin avantajı, çevrilecek metnin sayılabilir ve sabit olmasıdır.

Bu tür siteler HTTrack gibi yansılama araçlarıyla indirilebilir ya da Wayback Machine gibi arşivlerde saklanabilir (Jiménez-Crespo 2024, s. 177). Yani kaynak dosyalar tek seferde toplanabilir. Çevirmen dosyaları sıradan bir çeviri belleği aracında açar, etiketler korunur, yalnızca görünecek metin düzenlenir. Sonra dosyalar yeni dil klasörüne taşınır.

Buna karşılık statik sitelerde bağlantıların elle yönlendirilmesi, klasör adlarının düzenlenmesi ve metin gömülü görsellerin tek tek işlenmesi gerekir. Asıl sınırlama ise güncellemedir: kaynak sitede tek bir cümle değişse bile dosya yeniden çevirmene gider ve sunucuya tekrar yüklenir. Döngü uzadıkça diller arasında içerik farkı oluşur.

Dinamik web sitesi nasıl çalışır?

Dinamik sitede sayfa önceden hazır beklemez. Kullanıcı bir adresi çağırdığında sunucu, veritabanına bir sorgu gönderir, içeriği çeker, şablonla birleştirir ve sonucu HTML olarak tarayıcıya yollar. İstek yalnızca adresi değil; konum, dil tercihi ve önceki etkileşimler gibi bilgileri de taşır (Jiménez-Crespo 2024, s. 177).

Bu yapı PHP, Python, Ruby veya benzeri bir sunucu dili ile MySQL gibi bir veritabanı üzerine kurulur. Yönetimi genellikle WordPress, Drupal veya Joomla gibi bir içerik yönetim sistemi üstlenir. Çevrilecek metin artık dosyada değil, kayıtlarda durur; bu da çıkarma işini eklentilere ve bağlayıcılara bırakır.

Yerelleştirme açısından bu, sayfa sayısıyla iş hacmi arasındaki bağın kopması demektir. Bir ürün şablonu tek bir dosyadır ama binlerce ürün kaydını besler. Şablondaki sabit ifadeler bir kez çevrilir; ürün açıklamaları ise ayrı bir akışta ilerler. İki akışı birbirine karıştırmak, en sık görülen bütçe hatalarından biridir.

İstemci tarafı ve sunucu tarafı ayrımı

Dinamik siteler kendi içinde ikiye ayrılır. İstemci tarafında kod HTML, CSS veya JavaScript ile yazılır ve tarayıcının içinde çalışır; işletim sistemine erişimi sınırlıdır. Sunucu tarafında ise kod sunucuda çalışır ve geliştirici tercih ettiği programlama dilini kullanabilir (Jiménez-Crespo 2024, s. 177).

AJAX, sayfanın tamamını yenilemeden yalnızca bir bölümünü güncelleyen istemci tarafı bir tekniktir. Harita, video listesi veya sekme içerikleri böyle çalışır. Yerelleştirme açısından sonuç şudur: bu bölümlerdeki metin sayfa kaynağında görünmeyebilir ve gözle yapılan bir kontrolde kolayca atlanabilir.

Sunucu tarafında ise metin çoğunlukla PHP dosyalarının içinden ya da veritabanından gelir. Kullanıcı yalnızca üretilen HTML çıktısını görebilir, kodu göremez. Bu, kaynak metnin nerede tutulduğunu dışarıdan anlamayı zorlaştırır. Çeviri kapsamını belirlerken geliştiriciden bir içerik envanteri istemek, tahmin yürütmekten çok daha güvenlidir.

Ön yüz ve arka yüz: metin gerçekte nerede?

Ön yüz, ekranda gördüğünüz katmandır ve yerelleştirmenin asıl hedefidir. Arka yüz, sitenin nasıl çalıştığını, dosyaları, formları ve verinin nasıl saklandığını yöneten katmandır. Kitap bu ikisini “yüzey” ve “derin” yapı olarak da adlandırır (Jiménez-Crespo 2024, s. 176).

Arka yüzün yerelleştirilecek içeriği yok sanılır; oysa erişilebilirlik etiketleri ve arama motorlarının okuduğu üst veriler burada durur. Çeviri kapsamını yalnızca göz kararıyla belirlerseniz, sayfa başlıkları, görsel alternatif metinleri ve form hata mesajları kaynak dilde kalabilir. Bu tür eksikler genellikle yayına geçtikten sonra fark edilir.

Neyse ki bu katmanı görmek zor değil. Tarayıcının geliştirici menüsünden kaynak kodu görüntülendiğinde arka yüzün önemli bir bölümü okunabilir hâle gelir. Yerelleştirme öncesi yapılan hızlı bir kaynak kod taraması, çevrilmesi gereken ama listeye girmemiş metinlerin çoğunu ortaya çıkarır.

Statik ve dinamik web sitesi maliyeti nasıl değiştirir?

Kelime başına çeviri ücreti iki yapıda da benzerdir. Fark hazırlık, bütünleştirme ve bakım kalemlerinde ortaya çıkar. Statik sitede kurulum ucuz, güncelleme pahalıdır; dinamik sitede kurulum daha zahmetli, güncelleme ise ucuzdur. Aşağıdaki tablo bu dengeyi özetliyor.

Karar verirken tek seferlik maliyet yerine iki yıllık toplam maliyete bakmak daha doğrudur. Yılda birkaç kez güncellenen bir sitede statik yapının biriken mühendislik masrafı, dinamik kurulumun ilk yatırımını kısa sürede geçebilir. Tersine, hiç değişmeyecek bir kampanya sayfasında ağır altyapı gereksiz bir yük olur.

Ölçüt	Statik site	Dinamik site
Metnin yeri	HTML dosyalarının içinde	Veritabanı kayıtlarında
Çıkarma yöntemi	Dosyaların doğrudan aktarılması	Eklenti, bağlayıcı veya XLIFF dışa aktarımı
Bağlantı yönlendirme	Çoğunlukla elle	Büyük ölçüde otomatik
Güncelleme yükü	Her değişiklikte yeniden dosya alışverişi	Yalnızca değişen kayıtlar sıraya girer
Uygun olduğu durum	Küçük tanıtım ve kampanya siteleri	Katalog, blog ve mağaza siteleri

Hangi yapı hangi proje için uygun?

Sayfa sayısı az, içerik nadiren değişiyorsa statik yapı hâlâ makul bir tercihtir. On beş sayfalık kurumsal bir tanıtım sitesini iki dile açmak için ağır bir altyapı kurmanın karşılığı yoktur. Burada asıl risk teknik değil, kapsam risklerinin belgelenmemesidir.

Ürün kataloğu, blog veya kullanıcı yorumu barındıran bir sitede ise içerik sürekli akar. Böyle bir yapıda dinamik altyapı ve sürekli yerelleştirme akışı neredeyse zorunludur. İçerik yönetim sistemleri çoğunlukla çok dilli yönetim için hazır çözümler sunar ve bu, sektörde maliyetleri belirgin biçimde aşağı çekmiştir (Lynch 2006).

Arada kalan bir üçüncü durum daha var: statik görünen ama tek tek sayfaları elle çoğaltılmış siteler. Bunlar en zahmetli gruptur, çünkü tekrar eden metin dosyalar arasına dağılmıştır. Böyle bir sitede çeviriye başlamadan önce yapıyı sadeleştirmek, uzun vadede çeviri bütçesinden daha fazla tasarruf sağlayabilir.

Teklif öncesi netleşmesi gereken sorular

Yerelleştirme teklifinin isabetli olması için tedarikçinin sitenin yapısını bilmesi gerekir. Aksi halde teklif kelime sayısına bakar, mühendislik payını görmez ve iş ilerledikçe ek kalemler çıkar. Birkaç sorunun cevabı çoğu belirsizliği baştan kapatır.

Site hangi altyapıyla çalışıyor? İçerik yönetim sistemi var mı, sürümü nedir? Metnin ne kadarı şablonda, ne kadarı kayıtlarda? Görsellerin içinde gömülü yazı var mı? Formlar ve hata mesajları hangi dosyadan geliyor? Bu beş soru, projelerin çoğunda kapsamı doğru çizmeye yeter. Detaylı bir ön inceleme için iletişim sayfamızdan ulaşabilirsiniz.

Türkiye bağlamı

Türkiye’de küçük ve orta ölçekli işletmelerin siteleri genellikle hazır tema üzerine kurulu dinamik yapılardır. Bu, çok dilli açılım için iyi bir başlangıç noktasıdır; ancak temaların bir bölümü Türkçe metni doğrudan şablon dosyasına gömer. Böyle bir sitede menü ve düğme yazıları veritabanında değil, kod içinde durur ve otomatik çıkarma bunları atlar.

İkinci nokta dil yapısıyla ilgilidir. Türkçe sondan eklemeli olduğu için “Ürün”, “Ürünler”, “Ürünlerimiz” gibi biçimler tek bir kaynak dizeden türetilemez. İngilizceden gelen çoğullama şablonları Türkçede çoğu zaman bozuk sonuç verir. Dinamik olarak birleştirilen cümlelerde bu sorun daha da görünür hâle gelir.

Üçüncüsü hukuki metinlerdir. Kullanıcıdan veri toplayan formlar, KVKK kapsamında aydınlatma metni ve açık rıza alanları gerektirir. Bu metinler İngilizce sürümün birebir çevirisi olamaz; yerel mevzuata göre yeniden yazılır.

Bu sizin için ne anlama geliyor?

Sitenizi yabancı bir pazara açacaksanız, çeviri teklifi istemeden önce yapıyı belgelemeniz işi hem hızlandırır hem de sonradan çıkan sürprizleri azaltır. Aşağıdaki sıra, çoğu projede işe yarayan pratik bir başlangıçtır.

1. Sitenin altyapısını ve içerik yönetim sistemini yazılı olarak not edin.
2. Çevrilecek sayfaları listeleyin; kampanya ve arşiv sayfalarını kapsam dışında bırakıp bırakmayacağınıza karar verin.
3. Metin gömülü görselleri ve videoları ayrı bir listede toplayın.
4. Form alanlarını, hata mesajlarını ve otomatik e-postaları unutmayın.
5. Güncelleme sıklığını belirtin; ayda bir değişen bir site ile yılda bir değişen site farklı akış ister.

Bu listeyi hazırladığınızda aldığınız teklifler karşılaştırılabilir hâle gelir. Hizmet kapsamlarımızı çeviri hizmetleri sayfamızda bulabilir, örnek bir kapsam çalışması için teklif formunu kullanabilirsiniz.

Bu yazı genel bilgilendirme amaçlıdır, hukuki görüş değildir.

Sık sorulan sorular

Sitemin statik mi dinamik mi olduğunu nasıl anlarım?

En pratik yöntem adres satırına ve kaynak koduna bakmaktır. Adreste soru işareti ve ve işareti gibi karakterler varsa ya da site bir içerik yönetim sistemiyle yönetiliyorsa büyük olasılıkla dinamiktir. Sayfalar sabit .html uzantısıyla bitiyorsa statik olma ihtimali yüksektir.

Statik site çevirmek daha mı ucuzdur?

Metin hacmi aynıysa çeviri ücreti benzer olur. Fark hazırlık ve teslim aşamasındadır: statik sitede bağlantı yönlendirme ve klasör düzeni elle yapıldığı için mühendislik payı artar, dinamik sitede ise bu iş büyük ölçüde eklenti veya bağlayıcıyla otomatikleşir.

Dinamik sitede çevirmen kodu bozar mı?

Doğru kurulumda bozmaz. Çeviri araçları HTML ve XML dosyalarındaki etiketleri ve betik kodunu koruyup yalnızca ekranda görünecek metni gösterir. Risk, metnin araç dışında elle kopyalanıp yapıştırıldığı durumlarda ortaya çıkar.

Ürün açıklamaları veritabanındaysa nasıl çevrilir?

İçerik yönetim sistemi bu kayıtları XLIFF gibi bir değişim biçiminde dışa aktarabilir ya da bir bağlayıcı üzerinden çeviri platformuna gönderebilir. Ekran görüntüsü veya elle kopyalama yerine bu yolu tercih etmek, sonraki güncellemelerde tekrarı önler.

Kaynaklar

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, s. 176-178.
• Microsoft (2003). Computer Dictionary, 5. baskı, s. 564.
• Lynch, C. (2006). İçerik yönetim sistemleri ve çok dilli site maliyetleri üzerine değerlendirme.