Oyun Yerelleştirme Testi Nasıl Yapılır? Alfadan Altın Sürüme

Bir oyunun metni çevrildiğinde iş bitmiş sayılmaz. Metnin oyunun içinde nasıl davrandığı ayrı bir sorudur ve yanıtı ancak oynanabilir bir sürüm üzerinde alınır. Oyun yerelleştirme testi tam olarak bu soruyu yanıtlayan aşamadır.

İçindekiler

Kitap bu aşamayı, yerelleştirilmiş varlıkların oyuna entegre edilmesi ve testin başlaması olarak tanımlar. Tüm varlıkların birlikte sorunsuz çalışması, yüksek kaliteli bir son ürün ve deneyim için zorunludur (Jiménez-Crespo 2024, s. 218).

Bu yazıda testin nasıl kurgulandığını, hata ailelerini, ciddiyet düzeylerini ve sürüm adlarını ele alıyoruz. İlgili diğer kalite yazıları için bilgi merkezimize göz atabilirsiniz.

Test ne zaman başlar?

Test iki evreye ayrılır. Birinci evre entegrasyondan öncedir: çevrilmiş malzeme oyuna verilmeden önce dil kalitesi kontrol edilir ve düzeltilir. Bu, dosya üzerinde yapılan klasik bir gözden geçirmedir ve oyun oynanmadan yürütülebilir.

İkinci evre entegrasyondan sonra başlar. Tüm yerelleştirilmiş ve gözden geçirilmiş varlıklar oyun koduna geri derlenir, ardından “alfa” ya da “ilk oynanabilir alfa” adı verilen ön sürüm üretilir. Hatalar bu sürüm üzerinde aranır (Jiménez-Crespo 2024, s. 218–219).

Bu ayrım pratikte çok önemlidir. Dosya üzerinde kusursuz görünen bir çeviri, oyunun içinde taşabilir, kesilebilir veya yanlış ekranda görünebilir. Sadece birinci evreyi yapıp ikinciyi atlamak, yerelleştirme kalitesini yarım bırakmak demektir.

Testin kapsamı da baştan belirlenmelidir. Oyunun tamamını her dilde baştan sona oynamak çoğu projede mümkün değildir. Bunun yerine kritik yollar tanımlanır: ana hikâye akışı, alışveriş ve ayar ekranları, hata mesajları ve çok sık görülen arayüz öğeleri. Kapsam yazılı değilse test, testçinin sezgisine kalır.

Dört aşamalı hata döngüsü

Entegrasyon sonrası kalite süreci düzenli bir döngü izler. Kitap bu döngüyü dört adımda özetler ve her adımın ayrı bir çıktısı vardır (Jiménez-Crespo 2024, s. 219).

1. Hazırlık: test planı, kapsam, cihaz ve dil matrisi belirlenir.
2. Hata bulma: testçiler oyunu oynayarak sorunları tespit eder.
3. Hata raporlama: bulgular hata veritabanına ekran görüntüsü ve dize kimliğiyle girilir.
4. Hata gerilemesi: düzeltilen hatalar yeniden test edilir, kapanmayanlar açık kalır.

Döngü tek turda bitmez. Testçiler alfadan sonra “beta” sürümü de sınar ve tüm bulgular bir hata veritabanında toplanır. Veritabanının biçimi tedarikçiye göre değişir, ancak amaç aynıdır: hiçbir bulgunun kaybolmaması.

Bu döngü çeviri ekibiyle geliştirici arasında sürekli iletişim gerektirir. Kitap, hataların düzeltilmesinin geliştiricilerle işbirliğine dayandığını ve ilerlemenin belgelendiğini vurgular. Her turdan sonra “yapı” adı verilen yeni derlemeler üretilir.

Raporun niteliği döngünün hızını belirler. İyi bir kayıt hatanın nerede görüldüğünü, nasıl yeniden üretileceğini ve beklenen doğru davranışı içerir. “Menüde bir hata var” biçimindeki bir bildirim, düzeltmeyi yapacak kişiyi aynı yolu baştan aramaya zorlar.

Üç hata ailesi

Bulgular üç ana grupta toplanır. İşlevsellik hataları oyunun mekaniğiyle ilgilidir; beklenmedik çökmeler bu gruba girer. Bunlar dil ekibinin değil geliştirme ekibinin sorumluluğundadır, ancak yerelleştirilmiş sürümde ortaya çıkabilir.

Uygunluk hataları platformun, saganın veya yasal düzenlemelerin gerekleriyle ilgilidir. Terminoloji, kalıp ifadeler ve yerleşik kurallar bu başlıkta denetlenir. Platform sözlüğüne aykırı bir terim, yayımlanmayı engelleyebilecek kadar ciddidir.

Üçüncü grup dil hatalarıdır ve sektörde dilsel yerelleştirme kalite analizi olarak anılır. Kitap bu grubu ayrıntılı bir alt liste hâlinde verir; bu liste, dil testinin neye bakacağını belirleyen fiilî kontrol listesidir.

Ailelerin ayrı tutulması raporlama açısından da işe yarar. Bir metin taşması dil hatası gibi görünür ama kökeni arayüz tasarımında olabilir. Kaydın doğru aileye yazılması, düzeltmenin doğru ekibe gitmesini sağlar ve gereksiz gidip gelmeyi önler.

Oyunlara özgü dil hataları

Aşağıdaki tablo, kitapta sıralanan dil hatası kategorilerini ve bunların oyun içindeki tipik görünümlerini bir araya getiriyor. Kategoriler standart çeviri hatalarının ötesine geçer; oyunun teknik yapısından doğan sorunları da kapsar.

Kategori	Oyundaki tipik görünüm
Yanlış çeviri	Anlam kayması veya yanlış metnin gösterilmesi
Eksik çeviri	Kaynak dilde kalmış dize, eksik yer tutucu
Oyun terminolojisi	Sözlüğe aykırı terim, iç tutarsızlık
Yazım ve dilbilgisi	Yazım, noktalama, ek hataları
Yazı tipi sorunları	Özel karakterlerin bozuk görünmesi
Ses sorunları	Eksik ses, kesilme, yanlış dil, zamanlama
Bağlam hatası	Doğru ama yanlış yerde duran karşılık
Metin görüntüleme	Taşma, üst üste binme, kesilme
Teknik metin	Bozuk metin, yanlış çağrılan dize
Üslup	Karakter sesinin veya tonun kaybolması

Türkçe için bu listenin iki satırı öne çıkar. Yazı tipi sorunları, ç, ğ, ı, ö, ş ve ü karakterlerinin desteklenmediği durumlarda ortaya çıkar. Metin görüntüleme sorunları ise Türkçe karşılıkların kaynağa göre uzamasından doğar.

Bağlam hatası satırı da özellikle sinsidir. Metin dilbilgisi açısından kusursuz, sözlük anlamı açısından doğrudur; yalnızca bulunduğu yere uymaz. Bu tür bulgular otomatik denetim araçlarıyla yakalanmaz, ancak oyunu oynayan bir testçi tarafından fark edilir.

Ciddiyet düzeyleri ve öncelik kararı

Her hata aynı ağırlıkta değildir. Kitap dört düzeyli bir ölçek aktarır: “bu hâliyle satılamaz”, “oynanabilir ama oynanabilirliği etkiliyor”, “fark edilir ama oynanabilirliği etkilemiyor” ve “güçlükle görülür” (Bernal-Merino 2020, aktaran Jiménez-Crespo 2024, s. 219).

Bu ölçek, sınırlı zamanı nereye harcayacağınızı belirler. Yayın tarihi yaklaşırken tüm bulguları kapatmak mümkün olmayabilir. Kitap, oynanışı etkilemeyen bazı hataların nihai yayın adayında kalabildiğini açıkça belirtir.

Karar verirken görünürlük de hesaba katılmalıdır. Oyunun ilk on dakikasında görülen küçük bir yazım hatası, otuzuncu saatte görülen büyük bir üslup sorunundan daha çok konuşulur. Öncelik listesi, ciddiyet ve görünürlüğün kesişiminde kurulur.

Ölçeği kullanan kişinin de eğitilmiş olması gerekir. Aynı bulguya iki testçinin farklı düzey vermesi, raporu güvenilmez kılar. Proje başında birkaç örnek üzerinden ortak bir okuma yapmak, sonraki yüzlerce kaydın tutarlı sınıflandırılmasını sağlar.

Alfa, beta, altın sürüm, yayın adayı

Test sürecinin kendi sözlüğü vardır ve bu terimler sözleşmelerde geçer. Alfa, entegrasyon sonrası üretilen ilk oynanabilir sürümdür. Beta, daha olgun ve daha geniş kapsamlı test sürümüdür.

Ardışık test ve düzeltme turlarıyla üretilen derlemelere “yapı” denir. Son ürün “ön altın” veya “altın sürüm” olarak adlandırılır ve müşteriye teslim edilir; bu senaryoda müşteri genellikle yayıncıdır (Jiménez-Crespo 2024, s. 219).

Oyun yayımlanmaya hazır hâle geldiğinde “yayın adayı” olarak anılır. Bu aşamada yaş derecelendirme kurullarının onayı da tamamlanmış olmalıdır; kitap, bazı pazarlarda bu onay olmadan satışın mümkün olmadığını hatırlatır.

Bu terimleri sözleşmede kullanmak, teslim noktalarını netleştirir. “Çeviri teslim edildiğinde ödeme yapılır” ifadesiyle “altın sürüm onaylandığında ödeme yapılır” ifadesi çok farklı yükümlülükler doğurur. Tarafların hangi sürümde neyi taahhüt ettiği baştan yazılmalıdır.

Erişilebilirlik testi neden atlanıyor?

Kitap açık bir eksikliğe işaret ediyor: kalite testi oyun erişilebilirliğini de doğrulayabilir, ancak bu sektörde yaygın bir uygulama değildir (Jiménez-Crespo 2024, s. 220). Yerelleştirilmiş sürümün erişilebilirlik özellikleri çoğu zaman denetlenmeden kalır.

Oysa yerelleştirme bu özellikleri doğrudan etkiler. Altyazı boyutu, ekranda kalma süresi ve okuma hızı, dil değiştiğinde yeniden hesaplanmalıdır. Türkçe altyazıda uzayan bir satır, kaynak dilde sorunsuz olan bir zamanlamayı okunmaz hâle getirebilir.

Erişilebilirlik testini plana eklemek maliyetli bir ek değildir. Mevcut test turuna birkaç kontrol maddesi eklemek çoğu zaman yeterlidir: altyazı okunabiliyor mu, sesli ipuçlarının yazılı karşılığı var mı, metin ölçeklenebiliyor mu.

Bu kontroller yalnızca engelli oyunculara yaramaz. Okunabilir altyazı, net arayüz metni ve ölçeklenebilir yazı tipi tüm oyuncuların deneyimini iyileştirir. Erişilebilirliği ayrı bir iyilik kalemi değil, kalite ölçütünün parçası olarak görmek, bütçe tartışmasını da kolaylaştırır.

Türkiye bağlamı

Türkçe sürümlerde en sık karşılaşılan test bulguları, dilin yapısından kaynaklanıyor. Metin uzaması menülerde taşmaya, sondan eklemeli yapı ise değişkenli dizelerde yapışık veya yanlış eklere yol açıyor. Bunların ikisi de dosya üzerinde değil, ancak oyunun içinde görülüyor.

İkinci sık bulgu yazı tipi kaynaklı. Oyun için seçilen özel yazı tipi Türkçe karakterleri içermiyorsa, harfler kutucuk olarak veya yanlış biçimde görünüyor. Bu sorun geliştirme aşamasında çözülmezse test aşamasında düzeltilmesi zor ve pahalı oluyor.

Üçüncüsü ise Türkçe testçi bulmanın zorluğu. Testin dili bilen, oyunu oynayan ve hata raporu yazabilen kişilerce yapılması gerekiyor. Türkiye’de bu üç niteliği bir arada taşıyan profil sınırlı; bu yüzden test çoğu zaman çeviri ekibinin kendisine kalıyor. İdeal olan, çeviriyi yapan ile testi yapanın farklı kişiler olmasıdır.

Bu sizin için ne anlama geliyor?

Yerelleştirme bütçesi yaparken test kalemini ayrı gösterin. Çeviri fiyatının içinde eritilen bir test beklentisi, uygulamada çoğu zaman karşılıksız kalır ve sorunlar oyuncuya ulaşır.

1. Test planını çeviri sözleşmesiyle aynı anda hazırlayın; kapsamı ve dil matrisini yazın.
2. Testçilere oynanabilir bir sürüm ve dize kimliklerini içeren bir liste verin.
3. Hata veritabanında her kaydın kategorisi, ciddiyeti ve dize kimliği bulunsun.
4. Türkçeye özgü riskleri ayrı bir kontrol listesi yapın: yazı tipi, metin taşması, değişkenli dizeler.
5. Düzeltilen hataları yeniden test edin; kapanmamış kayıtları bir sonraki yapıya taşıyın.
6. Erişilebilirlik kontrollerini plana ekleyin, ayrı bir proje olarak ertelemeyin.

Bu adımlar, oyun yerelleştirme testi sürecini öngörülebilir kılar ve yayın gününde sürpriz olasılığını düşürür. Kapsam ve süreç seçeneklerini konuşmak isterseniz teklif formumuzu kullanabilir, çalışma alanlarımızı hizmetler sayfamızda inceleyebilirsiniz.

Sık sorulan sorular

Oyun yerelleştirme testi ne zaman başlar?

Çevrilen ve gözden geçirilen varlıkların oyun koduna geri derlenmesiyle başlar. Entegrasyondan önce dil kontrolü yapılır; entegrasyondan sonra ise oynanabilir sürüm üzerinde hata arama süreci işler.

Oyun testinde hatalar nasıl sınıflandırılır?

Üç aile kullanılır: işlevsellik hataları, uygunluk hataları ve dil hataları. Dil hataları ayrıca yanlış çeviri, eksik çeviri, terim sorunu, yazım, yazı tipi, ses, bağlam, metin taşması, teknik metin ve üslup başlıklarına ayrılır.

Hata ciddiyeti oyunlarda nasıl derecelendirilir?

Dört düzeyli bir ölçek yaygındır: bu hâliyle satılamaz, oynanabilir ama oynanabilirliği etkiliyor, fark edilir ama oynanabilirliği etkilemiyor, güçlükle görülür. Öncelik en üstteki düzeyden başlar.

Altın sürüm ile yayın adayı arasındaki fark nedir?

Testler ve düzeltmeler sonucu derlenen son ürün altın sürüm olarak müşteriye teslim edilir. Oyun yayına hazır hâle geldiğinde ise yayın adayı olarak anılır.

Kaynaklar

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, s. 218–220.
• Muñoz Sánchez, P. (2017). Localización de videojuegos. Síntesis.
• Game Accessibility Guidelines, gameaccessibilityguidelines.com.