Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
Web siteniz yalnızca Türkçe çalışıyorsa mevcut yazılımınızı değiştirmeden İngilizce, Almanca, Fransızca, Arapça veya ihtiyaç duyduğunuz diğer dilleri ekleyebiliriz. İsterseniz tamamen manuel key tabanlı dil sistemi, isterseniz Google Cloud Translation API ile otomatik çeviri, isterseniz otomatik çeviri + yönetim panelinden manuel düzeltme modeli kurulabilir.
Her sayfa açılışında API'ye tekrar çeviri göndermek yerine çeviri sonucu veritabanında/cache'de saklanabilir. Marka adları, teknik terimler ve çevrilmemesi gereken ifadeler glossary veya 'çevirme' kurallarıyla korunabilir.
Key sistemi, Google API, glossary ve SEO URL mimarisi
SEO uyumlu gerçek çoklu dil yapısında içerik, URL, slug, title, meta description, menü, kategori, ürün, blog ve gerektiğinde structured data her dil için yönetilebilir olmalıdır. Otomatik çeviri başlangıç sağlar; kritik satış metinlerinde manuel düzenleme katmanı kaliteyi yükseltir.
Hazır widget yerine mevcut uygulamanın içerik ve URL mimarisine göre gerçek çoklu dil sistemi kurulabilir.
İşletmenin içerik hacmine ve kalite beklentisine göre manuel, otomatik veya hibrit model seçilebilir.
Arayüz metinleri ve kritik içerikler editör tarafından yönetilir.
Yeni içerik ilk kez otomatik çevrilir ve saklanır.
API ilk taslağı üretir, editör düzeltir ve onaylar.
Arayüzde tekrar eden 'Sepete Ekle', 'Ücretsiz Kargo', 'Giriş Yap' gibi metinler doğrudan PHP dosyalarına gömülmek yerine dil anahtarı üzerinden çağrılabilir. Örneğin sepete_ekle anahtarı Türkçe, İngilizce ve Almanca karşılık taşır.
Yönetim panelinden key listesi düzenlenirse aynı metni onlarca template dosyasında tek tek değiştirmek gerekmez. Yeni dil eklendiğinde aynı key setine yeni çeviri sütunu veya kayıtları eklenir.
Key sistemi statik arayüz için idealdir; ürün ve blog gibi dinamik içeriklerde record_id + field + language mantığı daha esnektir.
Dinamik içeriklerde ana kaydı kopyalayarak üç ayrı ürün oluşturmak yerine çeviri tablosunda language, table_name, record_id, field ve value tutulabilir. Böylece stok, fiyat ve ürün kodu tek kaynaktan yönetilirken ad/açıklama her dilde farklı olur.
Alternatif olarak mevcut veritabanı yapısı uygunsa products_translations gibi ayrı tablolar kullanılabilir. Hangi modelin doğru olduğu sorgu yapısı, içerik hacmi ve mevcut script mimarisine göre seçilir.
SEO title, meta description ve slug da dil bazlı alan olarak tutulabilir.
Cloud Translation API uygulamanın gönderdiği metni hedef dile çevirebilir. Yeni ürün kaydedildiğinde background job İngilizce ve Almanca ilk çevirileri üretebilir.
API her sayfa görüntülenmesinde çağrılmamalıdır. Metin bir kez çevrilip veritabanında saklandığında maliyet, gecikme ve dış servis bağımlılığı azalır.
Cloud Translation Advanced glossary, batch ve başka gelişmiş özellikler sunar; hangi sürümün kullanılacağı içerik hacmine göre seçilir.
İlk çeviri API tarafından üretilir; editör yönetim panelinde metni kontrol edip değiştirebilir. Manuel değişiklik 'onaylandı' olarak işaretlenirse kaynak Türkçe metin değişmediği sürece tekrar API çevirisiyle üzerine yazılmaz.
Kaynak metin değiştiğinde sistem source_hash karşılaştırıp çeviriyi 'güncelleme gerekli' durumuna alabilir. Editör ister otomatik yeniden çevirir ister manuel düzenler.
Bu model binlerce üründe hız sağlarken ana satış sayfalarında insan kontrolünü korur.
Cloud Translation Advanced glossary, belirli terimlerin tutarlı çevrilmesi için özel sözlük mantığı sağlar. EKA Sunucu, VPS, VDS, NVMe gibi ifadelerin değiştirilmemesi veya belirli karşılıkla çevrilmesi tanımlanabilir.
Ürün kodu, SKU, marka, model ve değişken placeholder'lar ayrıca translate işleminden hariç tutulabilir.
Glossary özellikle teknik katalog ve aynı terimin binlerce üründe tutarlı görünmesi gereken projelerde değerlidir.
Google çok dilli sitelerde farklı dil sürümleri için ayrı URL kullanılmasını önerir. Örneğin /tr/urun/eka-sunucu, /en/product/eka-server ve /de/produkt/eka-server yapıları crawler'ın sürümleri ayrı ayrı keşfetmesini kolaylaştırır.
Sadece JavaScript ile sayfa metnini değiştirip URL'yi aynı bırakmak arama motoruna her dil için net kaynak sunmaz. Projenin mevcut URL mimarisine göre alt klasör, subdomain veya ülke domaini modeli seçilebilir.
Dil değiştirici aynı içeriğin eşdeğer dil URL'sine götürmelidir; kullanıcı her seferinde ana sayfaya gönderilmemelidir.
Her dil sayfası kendi eşdeğer dil sürümlerini rel=alternate hreflang ile işaretleyebilir. TR sayfasında EN ve DE bağlantıları varsa EN ve DE sayfalarında da geri dönüş işaretleri bulunmalıdır.
x-default, belirli bir dile hedeflenmeyen dil seçici veya varsayılan sayfa için kullanılabilir.
Canonical mümkün olduğunca aynı dildeki canonical URL'yi göstermelidir; tüm dilleri Türkçe sayfaya canonical yapmak yanlış sinyal oluşturabilir.
Tarayıcı dili ilk tercih önerisi için kullanılabilir ancak kullanıcı seçiminin önüne geçmemelidir. Google, kullanıcıları coğrafi IP ile zorunlu yönlendirmenin crawler'ın diğer sürümleri görmesini zorlaştırabileceğini belirtir.
Daha güvenli yaklaşım doğru dil için banner/öneri göstermek ve kullanıcının seçimini cookie ile hatırlamaktır.
Ülke ile dil aynı değildir; Türkiye'deki kullanıcı İngilizce, Almanya'daki kullanıcı Türkçe kullanmak isteyebilir.
10.000 ürünün tüm açıklamalarını tek HTTP isteğinde çevirmek timeout ve maliyet kontrolü açısından sağlıklı değildir. Queue/batch sistemiyle parça parça çevirmek, retry ve rate limit yönetimini kolaylaştırır.
Cloud Translation dokümantasyonu küçük text request'lerini optimize eder ve Advanced sürüm batch işlerini destekler. Uygulama kendi kuyruğunda da yüzlerce kaydı kontrollü işleyebilir.
Her kayıtta source_hash tutularak değişmeyen içerik tekrar çevrilmeyebilir.
Cloud Translation fiyatlandırması kullanılan model ve karakter hacmine göre değişebilir. Bu nedenle API çağrısını sayfa görüntülemeye bağlamak yerine içerik oluşturma/güncelleme anında çalıştırmak daha öngörülebilirdir.
Çeviri cache, hash kontrolü, sadece değişen alanları gönderme ve manuel onaylı metni yeniden çevirmeme maliyeti azaltır.
Yönetim panelinde ay boyunca çevrilen karakter ve başarısız job sayısı raporlanabilir.
Tedarikçi XML entegrasyonu yeni ürünü Türkçe ekledikten sonra queue'ya translation job bırakabilir. Ürün adı, açıklama ve özellikler EN/DE oluşturulurken SKU, barkod ve marka gibi alanlar korunur.
Tedarikçi sonraki gün açıklamayı değiştirirse source_hash değişimi tespit edilerek yalnız değişen alan yeniden çevrilebilir.
Bu yapı XML ürün aktarımı + kur entegrasyonu + çoklu dil sistemini tek otomasyon zincirine dönüştürebilir.
Hayır. Arapça, Farsça ve İbranice gibi RTL dillerde layout yönü, ikon sırası, form hizası, breadcrumb ve bazı bileşenlerin yön davranışı da ele alınmalıdır.
HTML dir=rtl, CSS logical properties ve tema bileşenleri test edilmelidir. Yalnız metni Arapçaya çevirmek iyi kullanıcı deneyimi sağlamaz.
Logo, ürün görseli veya görsel içindeki yazılar da hedef pazara göre ayrıca hazırlanabilir.
Yeni bir key veya içerik henüz İngilizceye çevrilmediyse sistem ana dil fallback kullanabilir. Böylece boş başlık veya PHP warning oluşmaz.
Yönetim paneli eksik çevirileri filtreleyip yüzde tamamlama gösterebilir. Kritik sayfaların yayına alınması için minimum çeviri tamamlanma oranı belirlenebilir.
Fallback kullanıcı deneyimini korur ancak SEO sayfalarında kalıcı çözüm olarak bırakılmamalıdır.
Site adresinizi, mevcut yazılımı, hedef dilleri ve içerik sayısını iletin. İlk aşamada arayüz metinlerinin nerede tutulduğu, dinamik içerik modeli ve URL yapısı hakkında genel uygulanabilirlik değerlendirilebilir.
Google Translation API mi manuel key sistemi mi yoksa hibrit model mi daha uygun olduğu içerik hacmine ve editör iş akışına göre belirlenir.
Kaynak kod incelemesi gerekiyorsa hangi erişimin neden gerektiği ayrıca açıklanır; ilk aşamada şifre göndermeniz gerekmez.
Örnekler mimariyi anlatmak içindir; canlı projede tablo ve route yapısı mevcut yazılıma göre uyarlanır.
Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
echo $dil['sepete_ekle'];language | table_name | record_id | field | value
tr | products | 52 | name | EKA Sunucu Paketi
en | products | 52 | name | EKA Server Package
de | products | 52 | name | EKA Serverpaket<link rel="alternate" hreflang="tr" href="https://site.com/tr/urun/eka-sunucu">
<link rel="alternate" hreflang="en" href="https://site.com/en/product/eka-server">
<link rel="alternate" hreflang="de" href="https://site.com/de/produkt/eka-server">
<link rel="alternate" hreflang="x-default" href="https://site.com/">Eka Sunucu = Eka Sunucu
VPS = VPS
VDS = VDS
NVMe = NVMe
Sanal Sunucu = Virtual Server
Ekran Kartlı Sunucu = GPU ServerSite adresinizi, eklemek istediğiniz dilleri ve yaklaşık ürün/sayfa sayısını iletin. Manuel, Google Translation API veya hibrit modelden hangisinin daha uygun olduğunu netleştirelim.
Çeviri API özellikleri ve çoklu dil SEO için Google Cloud ile Google Search Central dokümantasyonunu esas alıyoruz.
Çoklu dil sistemi XML ürün aktarımı, otomatik kur ve teknik SEO yapısıyla birlikte çalışabilir.
Manuel key, API, SEO URL ve ürün çevirilerinde en çok sorulan noktaları topladık.
Evet. Kaynak kod ve veri yapısı uygunsa mevcut siteye sonradan çoklu dil altyapısı eklenebilir.
Hayır. Gerçek çoklu dilde URL, meta, slug, menü ve dinamik içerik her dil için yönetilebilir.
Evet. Otomatik ilk çeviri için API entegre edilebilir.
Önerilmez. Çeviri bir kez üretip veritabanında/cache'de saklanabilir.
Hibrit yapıda manuel onaylı kayıt korunabilir ve kaynak değişmedikçe tekrar çevrilmez.
Evet. Glossary ve exclude kuralları kullanılabilir.
Hayır. Alan bazlı kuralla SKU, barkod, marka/model gibi değerler çeviri dışında bırakılır.
Evet ancak queue/batch yapısıyla kontrollü işlenmesi daha doğrudur.
Google Cloud Translation kullanım/model bazlı fiyatlandırılır; güncel fiyat Google Cloud sayfasından kontrol edilmelidir.
SEO hedefleniyorsa ayrı dil URL'leri genellikle daha sağlıklı ve Google tarafından önerilen yaklaşımdır.
Eşdeğer dil sürümlerini Google'a anlatmak için güçlü bir işarettir.
Hayır. Google, hreflang kullanılıyorsa mümkün olduğunca aynı dilde canonical sayfayı belirtmeyi önerir.
Belirli bir dil/ülkeye hedeflenmeyen varsayılan veya dil seçici sayfayı işaretlemek için kullanılabilir.
Öneri yapılabilir ancak kullanıcı seçimi korunmalı ve crawler'ın diğer dil sürümlerini görmesi engellenmemelidir.
Evet, ancak RTL tasarım kontrolleri de yapılmalıdır.
Evet. Sitemap veya hreflang alternatifleri dil sürümlerini ilişkilendirebilir.
Evet. /tr/urun/... ve /en/product/... gibi yerelleştirilmiş slug kullanılabilir.
Evet. Ürün eklendikten sonra translation queue tetiklenebilir.
Evet. source_hash veya updated_at takibi ile değişen alanlar yeniden çevrilebilir.
Doğru fallback yapısında ana dil gösterilir ve eksik kayıt yönetim panelinde raporlanır.
Mevcut eklenti ve özel geliştirme seçenekleri analiz edilerek uygulanabilir.
Evet. Template metinleri key'e taşınıp dinamik içerikler için translation tablosu kurulabilir.
Evet. Kaynak koda veya uygun API yapısına erişim varsa yazılımın bizden alınmış olması gerekmez.
Site adresi, kullandığınız yazılım, hedef diller ve yaklaşık ürün/sayfa sayısı yeterlidir.
Site adresinizi, eklemek istediğiniz dilleri ve yaklaşık ürün/sayfa sayısını iletin. Manuel, Google Translation API veya hibrit modelden hangisinin daha uygun olduğunu netleştirelim.