01. Oyun yerelleştirme aslında ne kapsıyor?
Bir oyunun yerelleştirme katmanı, görünür dilden çok daha geniştir. Arayüz dizgileri (menü, buton, hata mesajı), in-game diyaloglar, görev açıklamaları, sistem bildirimleri, tutorial metinleri, başarım/achievement adları, mağaza listeleme metinleri, patch notları ve gizlilik politikası — hepsi ayrı bağlamlarda çalışan içeriklerdir.
Biz bu içerikleri tek bir teslimat gibi değil, bağlamına göre ayrılmış akışlar olarak ele alırız. Diyalog çevirmeni karakter tonunu korur; UI çevirmeni karakter limitini ve buton genişliğini düşünür; mağaza metni yazan kişi App Store/Steam kuralları ve hedef pazarın arama davranışıyla çalışır. Aynı oyunun Almanca ve Arapça sürümlerinde, satır uzunluğundan yazı yönüne kadar farklı kararlar gerekebilir; bu kararları lokalize ederken kaynak ekiple birlikte alırız.
Konsol başlıklarında platform sertifikasyonu (Sony TRC, Microsoft XR, Nintendo Lotcheck) sözlüklerine uyum da kapsamımıza dahildir; gerekli terim listesi varsa onunla çalışırız, yoksa platform şartlarına göre kuruluruz.
02. Hangi dosya formatlarıyla çalışıyoruz?
Genellikle kaynak dosyaları kendi formatlarında alır, dönüştürmeden işleriz. Bu hem versiyon takibini hem de placeholder bütünlüğünü korur.
Düzenli çalıştığımız formatlar:
- Unity projelerinde `.po`, `.csv`, JSON ve I2 Localization tabloları
- Unreal Engine için `.po` ve string tabloları (`.uasset` export edilmiş)
- Mobil: Android `strings.xml`, iOS `Localizable.strings` ve `.stringsdict`
- Endüstri standardı: XLIFF 1.2/2.0, TMX, TBX
- Web tabanlı oyunlar / launcher: JSON i18n bundle'ları, gettext `.po/.pot`
- Mağaza metinleri: Steam ve App Store/Google Play şablonlarına uygun düz metin veya CSV
Dosya içinde `{playerName}`, `%d`, `<color=...>`, ICU MessageFormat veya HTML span gibi placeholder ve etiket varsa, bunlara dokunmadan etrafındaki metni çeviririz. Çoğul kuralları (özellikle Rusça, Arapça, Lehçe için ICU plural) hedef dile göre yeniden kurulur. Eğer build pipeline'ınız özel bir formatla çalışıyorsa, küçük bir örnek dosyayla başlayıp dönüşüm ihtiyacını birlikte değerlendiririz.
03. Tipik bir oyun projesi nasıl ilerliyor?
Sürecin omurgası dört aşamada oturur: kaynak inceleme, terminoloji kurulumu, çeviri ve in-context kontrol.
Önce kaynak dosyaları, mevcut build'i (mümkünse APK, IPA veya geliştirici sürümü) ve varsa tasarım dokümanını inceleriz. Karakter limitleri, ses dosyası referansları, lip-sync gereksinimi varsa erken tespit edilir. Ardından terminoloji çalışması: silah, yetenek, mekân adları, oyuncu hitap biçimi (resmi/samimi), küfür ve şiddet seviyesinin hedef pazarda nasıl ele alınacağı bir style guide içinde belgelenir.
Çeviri aşamasında çevirmenler memoQ, Trados veya Crowdin/Lokalise gibi sizin tercih ettiğiniz TMS üzerinde çalışır. Translation memory ve glossary canlıdır; aynı oyunun ikinci sürümünde önceki çeviriler otomatik olarak gelir. Çeviri sonrası editör pass'i ardından in-context review: çeviriler test build'inde görüntülenir, taşan satırlar ve bağlamsız kalan dizgiler düzeltilir.
Son olarak dosyalar build'inize uygun şekilde teslim edilir; gerekirse pull request açar veya repo'ya direkt commit ederiz.
04. Glossary ve translation memory ne işe yarıyor?
Bir oyunda "mana", "stamina", "rage" gibi terimler her geçtiğinde farklı çevrilirse oyuncu deneyimi parçalanır. Glossary, bu terimlerin hedef dildeki karşılığını ve nasıl çevrilmeyeceğini (örneğin marka adlarını) sabitler. Yeni içerik geldiğinde çevirmen aynı terimi otomatik görür.
Translation memory ise cümle düzeyinde çalışır. Daha önce çevrilmiş bir diyalog satırı yeni sürümde tekrar ettiğinde, sistem onu önerir; siz de bu segmentler için indirimli oran üzerinden ücretlendirilirsiniz. Uzun soluklu live-service oyunlarda TM, ikinci yıldan itibaren maliyetin %20-40'ını düşürebilir.
Mevcut bir TM veya glossary'niz varsa (TMX/TBX) onu içe aktarırız. Yoksa ilk pilot dil çalışması sırasında birlikte kurarız; sonraki diller bu temele yaslanır. Glossary ve TM her zaman size aittir, projenin sonunda eksiksiz teslim edilir.
05. Yerelleştirmeyi oyunun içinde nasıl test ediyoruz?
Statik dosyada doğru görünen bir çeviri, ekrana yerleştiğinde butondan taşabilir, satır kayabilir veya cinsiyet/çoğul kuralı yanlış tetiklenebilir. LQA (Localization Quality Assurance) bu sorunları yakalar.
Bize test build'i veya web preview ortamı sağlarsanız, LQA tester'ları her menüyü, her diyalog dalını, her hata ekranını hedef dilde gezerek kontrol eder. Bulgular bir hata listesinde (genelde Jira, Notion veya CSV) raporlanır: kırpılan metin, yanlış kullanılan placeholder, kültürel olarak hatalı görsel-metin eşleşmesi, eksik çeviri. Çevirmen-editör ekibi düzeltir, gerekirse sizin developer'lar UI'da küçük ayar yapar.
LQA'yı çeviriyle birlikte veya ayrı bir hizmet olarak alabilirsiniz. Hızlı bir mobil hyper-casual oyun için 4-8 saatlik LQA yetebilirken, geniş bir RPG'de dil başına 30-60 saat ayırmak gerekir. Kapsamı kaynak dosya büyüklüğü ve menü/diyalog dağılımına bakarak birlikte belirleriz.
06. Live-service ve sürekli güncellenen içerik nasıl yönetiliyor?
Tek seferlik bir mobil oyun ile haftalık patch çıkan bir live-service başlığın iş akışı aynı değildir. Sürekli güncellenen projelerde çalışırken iki model öneriyoruz.
Sürekli akış (continuous localization): Crowdin, Lokalise veya kendi sisteminize webhook ile bağlanırız. Geliştiriciler yeni dizgileri repo'ya push ettiğinde, çevirmenler bir-iki iş günü içinde aynı sistem üzerinden çevirir; sürüm öncesi LQA hızlı bir pass alır. Bu model haftalık veya iki haftalık sprint temposuna uyar.
Sprint paketi: Her sürüm öncesi belirli bir tarihte tüm yeni içerik tek paket olarak gelir, çevrilir ve geri teslim edilir. Daha öngörülebilir maliyet üretir; aylık veya iki aylık sürüm temposuna uygundur.
İki modelde de translation memory canlıdır, ekip aynıdır. Acil hotfix metinleri için ayrı bir hızlı kanal tanımlarız; genellikle 24 saat içinde dönüş sağlanır. Sürüm temposunu paylaşırsanız, hangi modelin maliyet/hız dengesi için size uygun olduğunu birlikte konuşuruz.
07. Ücret ve pilot çalışma mantığı
Oyun yerelleştirmede ücret üç bileşenden oluşur: çeviri (yeni kelime + TM eşleşmesi), editör pass'i ve LQA saati. Mağaza metni, patch notu gibi pazarlama ağırlıklı içerikler ayrı kalemde değerlendirilir çünkü transcreation gerektirir.
Genellikle bir pilot dil ile başlamayı öneriyoruz — çoğu zaman İngilizce kaynak için Almanca veya Türkçe. Pilot, hem terminolojiyi hem iş akışını oturtur; sonraki diller (Fransızca, İspanyolca LATAM, Rusça, Arapça, Çince Basitleştirilmiş) bu temel üzerine eklenir. Pilotun süresi ve maliyeti, kaynak kelime sayısı ve UI/diyalog/mağaza dağılımına göre belge yüklendikten sonra netleşir.
Büyük live-service projelerde aylık retainer modeli (sabit aylık kapasite + üzerini birim fiyatla) uzun vadede daha öngörülebilir olur. Kapsamı ve tempoyu birlikte değerlendirip hangi modelin size uygun olduğunu birlikte kararlaştırırız.