Çok Dilli İçerik Saklamak: Veritabanı Yapısı Kararı
Siteniz Türkçe yayında ve İngilizce eklenecek. İlk akla gelen çözüm tabloya bir sütun daha eklemek: başlık ve başlık İngilizce. İki dil için çalışır. Üçüncü dilde ne olacağını düşünmeden verilen bu karar, sonradan değiştirilmesi en pahalı kararlardan biridir.
Bu yazı, çok dilli veri saklama yapılarını ele alıyor.
Her Dile Bir Sütun
| Artısı | Eksisi |
|---|---|
| Kurulumu çok kolay | Yeni dil şema değişikliği ister |
| Sorgular basit | Tablo hızla genişler |
| Birleştirme gerekmez | Boş sütunlar birikir |
Birinci satırın sağ tarafı asıl sorundur: her yeni dil için tabloya sütun eklemek, on çevrilebilir alanı olan bir tabloda beş dil için elli sütun demektir — ve her yeni dil canlı veritabanında şema değişikliği gerektirir.
Bu yapı iki dilde makul görünür.
Beş dilde yönetilemez hâle gelir.
Bu nedenle yalnızca dil sayısının kesin ve sabit olduğu durumlarda tercih edilmelidir.
Her Dile Bir Satır
- Ana tablo dilden bağımsız verileri tutar.
- Çeviri tablosu dile özel alanları tutar.
- İkisi kimlikle bağlanır.
Bu yapı en yaygın ve en esnek çözümdür: yeni bir dil eklemek yalnızca çeviri tablosuna satır eklemek demektir — şema hiç değişmez ve dil sayısı sınırsızdır.
Ana tabloda fiyat, stok, tarih gibi ortak veriler durur.
Çeviri tablosunda başlık, açıklama gibi metinler bulunur.
Bu ayrım baştan doğru yapılmalıdır.
Hangi Alan Nerede
- Sayısal ve tarihsel veriler ortaktır.
- Metinler çevrilir.
- Adres parçası da çevrilebilir.
Üçüncü madde sık atlanır ama arama motoru açısından önemlidir: her dil için ayrı bir adres parçası tutmak, İngilizce sayfanın İngilizce bir adrese sahip olmasını sağlar — Türkçe adresli bir İngilizce sayfa hem kullanıcı hem arama motoru için tuhaf durur.
Bu alan çeviri tablosunda tutulmalıdır.
Her dilde benzersiz olmalıdır.
Aynı dilde iki aynı adres bulunmamalıdır.
Eksik Çeviri Davranışı
| Yaklaşım | Sonuç |
|---|---|
| Varsayılan dile düş | Sayfa çalışır |
| Boş göster | Bozuk görünür |
| Sayfayı hiç gösterme | Bazı durumlarda doğru |
Birinci satır pratik bir çözümdür ama dikkat ister: çevirisi olmayan alanı varsayılan dilden göstermek sayfayı çalışır tutar ama karışık dilli bir görünüm üretir — kullanıcı yarısı İngilizce yarısı Türkçe bir sayfa görebilir.
Bu, tamamen boş bir alandan yine de iyidir.
Üçüncü satır ise eksik çeviri oranı yüksekse tercih edilir.
Yarım çevrilmiş sayfayı arama motoruna sunmamak daha iyidir.
Sorgu Karmaşıklığı
- Her listeleme birleştirme gerektirir.
- Dil koşulu her sorguya eklenir.
- Unutulursa yinelenen satır çıkar.
Üçüncü madde en sık yaşanan hatadır: dil koşulu eklenmemiş bir birleştirme, her kaydı dil sayısı kadar tekrar listeler — üç dilli bir sitede ürün listesi üç katına çıkar.
Bu hata gözle hemen fark edilir ama sayımlarda gizlenir.
Merkezî bir sorgu katmanı bu koşulu otomatik ekleyebilir.
İkinci madde bu nedenle otomatikleştirilmelidir.
Dizin İhtiyacı
- Kimlik ve dil birlikte dizinlenmeli.
- Adres alanı dizinlenmeli.
- Benzersizlik kuralı konulmalı.
Birinci madde performansı belirler: çeviri tablosunda kayıt kimliği ve dil kodunu birlikte içeren bir dizin, her sayfa yüklemesinde yapılan aramayı anında bitirir — bu dizin olmadan tablo büyüdükçe her sayfa yavaşlar.
Üçüncü madde ise veri bütünlüğünü korur.
Aynı kayda aynı dilde iki çeviri olmamalıdır.
Bu kural veritabanı seviyesinde tanımlanmalıdır.
Arayüz Metinleri
| İçerik türü | Saklama yeri |
|---|---|
| Ürün ve sayfa içerikleri | Veritabanı |
| Buton ve menü metinleri | Dil dosyaları |
| Hata mesajları | Dil dosyaları |
İkinci satır önemli bir ayrımı gösterir: arayüz metinlerini veritabanında tutmak her sayfa yüklemesinde gereksiz sorgu üretir — bu metinler kodla birlikte gelen dil dosyalarında durmalıdır.
Dil dosyaları önbelleklenebilir.
Ayrıca sürüm kontrolünde izlenebilir.
İçerik ise düzenlenebilir olmalıdır ve veritabanına aittir.
Sonradan Geçiş
- Sütun yapısından satır yapısına geçilebilir.
- Veri taşıma betiği yazılır.
- Kod da güncellenmelidir.
Üçüncü madde geçişin gerçek maliyetini gösterir: veriyi taşımak kolaydır ama o alanlara erişen tüm sorguların ve şablonların güncellenmesi gerekir — bu, projenin büyüklüğüne göre günler alabilir.
Bu nedenle karar baştan doğru verilmelidir.
İkiden fazla dil ihtimali varsa satır yapısı seçilmelidir.
Başlangıçtaki küçük ek çaba, sonradan büyük tasarruf sağlar.
Çok dilli yapılar daha fazla tablo ve dizin gerektirir; Linux hosting barındırma ile veritabanı kaynaklarınızı ihtiyacınıza göre ölçekleyebilirsiniz.
Sonuç
Çok dilli yapı kararı geri dönüşü pahalı bir karardır. Her dile sütun eklemek iki dilde makul görünse de on çevrilebilir alanı olan bir tabloda beş dil için elli sütun demektir. Ayrı çeviri tablosu kullanın: yeni dil yalnızca satır eklemektir. Dil koşulunu merkezî katmanda otomatik ekleyin — unutulan bir koşul her kaydı dil sayısı kadar tekrar listeler.
Sıkça Sorulan Sorular (SSS)
Hangi yapıyı seçmeliyim?
İkiden fazla dil ihtimali varsa ayrı çeviri tablosu. Her dile sütun eklemek iki dilde makul görünür ama beş dilde yönetilemez hâle gelir ve her yeni dil canlı veritabanında şema değişikliği gerektirir. Çeviri tablosunda yeni dil yalnızca satır eklemektir.
Çevirisi olmayan alanı ne yapmalıyım?
Varsayılan dilden göstermek sayfayı çalışır tutar ama karışık dilli bir görünüm üretir; kullanıcı yarısı İngilizce yarısı Türkçe bir sayfa görebilir. Yine de boş alandan iyidir. Eksik çeviri oranı yüksekse o sayfayı hiç yayımlamamak daha doğru olabilir.
Ürünler listede birkaç kez görünüyor?
Birleştirmeye dil koşulu eklenmemiş. Bu durumda her kayıt dil sayısı kadar tekrar listelenir; üç dilli bir sitede liste üç katına çıkar. Dil koşulunu merkezî bir sorgu katmanında otomatik ekleyin.
Buton metinlerini de veritabanında tutmalı mıyım?
Tutmayın. Arayüz metinlerini veritabanında saklamak her sayfa yüklemesinde gereksiz sorgu üretir; bunlar kodla gelen dil dosyalarında durmalıdır. Dil dosyaları önbelleklenebilir ve sürüm kontrolünde izlenebilir.
