01. Mobil uygulama yerelleştirme aslında ne demek?
Mobil uygulama yerelleştirme, kullanıcı arayüzündeki metinlerin başka bir dile çevrilmesinden ibaret değildir; kaynak dosya formatına saygılı bir mühendislik işidir. iOS tarafında `Localizable.strings`, çoğul kuralları için `Localizable.stringsdict`, App Store için `metadata.json` ve ekran açıklamaları; Android tarafında `res/values-{locale}/strings.xml`, `plurals` blokları, Play Console listing metinleri.
Her biri kendi sözdizimiyle çalışır. Android'de `%1$s` placeholder'ı, iOS'ta `%@` ve `%1$@` ifadeleri çeviri sırasında bozulursa uygulama crash eder veya kullanıcıya `Hello %@` gibi metin gösterir. Aynı şekilde Arapça gibi RTL dillerde yön bilgisi, Almanca'da bileşik kelimelerden doğan UI taşması, Rusça'da çoğul kuralındaki üç biçim — bunlar çeviri sürecinin parçasıdır.
Biz dosyayı ham haliyle alır, key'leri ve formatlamayı bozmadan çeviririz. Çıktı; geliştiricinin doğrudan repo'ya commit edebileceği biçimdedir.
02. Bir mobil yerelleştirme projesi bizde nasıl ilerler?
İlk adım kaynak dosya incelemesidir. Bir `strings.xml` ya da `Localizable.strings` örneği paylaştığınızda; key sayısı, placeholder yoğunluğu, çoğul ve cinsiyet kuralları, mevcut yorum satırları ve hedef dil sayısı üzerinden kapsamı çıkarırız. Bu aşamada bir glossary taslağı oluştururuz — uygulama adı, marka terimleri, ekran isimleri, çevrilmeyecek özel kelimeler.
Çeviri katmanında her dil için iki kişilik akış işler: çevirmen ve editör. Çıktı paylaşılan TMS'e (Crowdin, Lokalise, Phrase) veya XLIFF olarak doğrudan ekibinize gider. Ardından in-context review geçilir: simulator veya gerçek build üzerinde ekranlar açılır, taşma, kesilme, çoğul kuralı hatası ve bağlam kayması tek tek loglanır. Bulgular düzeltilip son dosya teslim edilir.
Teslim, projeniz bir kez yapılan iş ise ZIP veya pull request; sürekli güncellenen bir uygulama ise TMS'de senkron şeklinde kurulur.
03. Hangi dosya formatlarıyla çalışıyoruz?
Mobil tarafta doğrudan çalıştığımız formatlar: Android için `strings.xml`, `arrays.xml`, `plurals.xml`; iOS için `Localizable.strings`, `Localizable.stringsdict`, `InfoPlist.strings`; React Native ve Flutter projelerinde `.json` ve `.arb`; Xamarin / .NET MAUI tarafında `.resx`. App Store ve Google Play metadata için `description`, `whatsNew`, `keywords` ve ekran görüntüsü altyazıları ayrı sürdürülür.
TMS taraflı ise XLIFF 1.2 ve 2.0, gettext `.po/.pot`, YAML, properties ve CSV/TSV export-import akışlarını destekleriz. Crowdin, Lokalise, Phrase ve POEditor üzerinde proje üyesi olarak çalışabilir; ekibinizin tercih ettiği başka bir sistemse oraya erişim ile başlarız.
Kaynak dosyanız sıra dışı bir format ise (örneğin custom JSON schema, Firebase Remote Config export) önce küçük bir örnek üzerinden mapping kuralını belirler, sonra tüm hacmi alırız. Geliştirici ekibin formatı dönüştürmek için ek iş yapması beklenmez.
04. Glossary, translation memory ve style guide ne işe yarar?
Bir uygulamada "Cart" kelimesi sayfanın birinde "Sepet", diğerinde "Alışveriş Listesi" olarak çevrilirse kullanıcı kafa karışıklığı yaşar; üstelik bu hata sürüm sürüm üst üste birikir. Glossary bu tutarsızlığı baştan kapatır: marka terimleri, ekran adları, buton metinleri ve çevrilmeyecek özel isimler her dil için sabitlenir.
Translation memory ise tekrar eden cümleler için kaldıraçtır. Bir uygulamada "İptal", "Devam Et", "Daha Fazla Bilgi" gibi mikro metinler onlarca yerde geçer. TM bunları bir kez çevirdiğimizde sonraki sürümlerde otomatik önerir; siz hem para hem zaman kazanırsınız. Yeni metnin TM eşleşme oranı (100% match, fuzzy, no match) teklif kaleminde ayrı görünür.
Style guide, marka tonunu belirler: resmi mi samimi mi konuşacağız, kullanıcıya "sen" mi "siz" mi diyeceğiz, tarih formatı hangi standart. Bu üç araç birlikte çalıştığında çeviri kalitesi sürüm geçtikçe düşmek yerine yukarı doğru gider.
05. Çeviri uygulamada nasıl göründüğünü test ediyor muyuz?
Evet, ve bu adım yerelleştirme işinin yarısıdır. Buna sektörde LQA (Linguistic Quality Assurance) denir. Bir test cihazı veya simulator üzerinde uygulamanın çevrilmiş dilini açar, ekran ekran gezeriz.
Kontrol ettiğimiz şeyler: butonda metin taşıyor mu (Almanca'da çok sık), iki satıra düşüp tasarımı bozuyor mu, çoğul kuralı yanlış mı tetiklendi (1 ürün / 2 ürün / 5 ürün), placeholder boş mu çıktı, RTL dilde ikon hizalaması bozuldu mu, bir ekran tamamen çevrilmemiş olarak kaldı mı.
Bulguları ekran görüntüsü + key referansı + öneri ile bir tabloya yazarız. Geliştirici ekip bu listeyi sprint içinde işler. Build hazır olduğunda ikinci tur LQA yapılabilir. Bazı müşteriler LQA'yı kendi QA ekibine yaptırır; bu durumda biz yalnızca dilsel hataları onların raporundan alıp düzeltiriz.
LQA dahil edilmeden teslim edilen mobil yerelleştirmeler genelde üçüncü sürümde tasarım borcu olarak geri döner.
06. Sürekli güncellenen bir uygulamayla nasıl çalışıyoruz?
Mobil uygulama bir kez çevrilip biten bir belge değil; her sprintte yeni ekran, yeni özellik, yeni mikro metin eklenir. Bu yüzden ilk projeden sonra sürüm akışını birlikte tasarlarız.
En yaygın iki model: toplu sürüm modeli — iki haftada bir veya sürüm öncesi yeni key'ler toplanır, hepsi birlikte gönderilir, 2-3 iş günü içinde döner. Sürekli akış modeli — TMS entegrasyonu ile her yeni key otomatik bize düşer, 24-48 saat içinde çevrilir, geliştirici pull etmeden önce LQA bayrağı eklenir.
GitHub veya GitLab repo'nuza yerelleştirme branch'i üzerinden pull request açabiliriz; ya da yalnızca dosya teslim edip merge'i ekibinize bırakabiliriz. Acil düzeltmeler (kritik metin hatası, store reddi) için ayrı bir hızlı kanal tanımlanır.
Önemli olan ekibinizin sürüm temposuna uyan bir ritim kurmamız — "her dil için ayrı e-posta zinciri" hızla tıkanır.
07. Mobil yerelleştirmede ücret nasıl çıkıyor?
Belge tercümesinde sayfa veya karakter sayar; mobil yerelleştirmede mantık farklıdır. Üç bileşen var.
Birincisi kaynak kelime sayısı, TM eşleşmesi çıkarıldıktan sonra. 100% match olan satırlar düşük katsayı, fuzzy match orta, yeni metin tam ücret. İkincisi dil sayısı; pahalı diller (Japonca, Korece, İskandinav dilleri) ile yaygın dillerin (İngilizce, Almanca) saat ücreti farklıdır. Üçüncüsü LQA saatleri — ekran sayısına ve dil başına yaklaşık süre üzerinden ayrı kalem.
App Store / Play Store metadata, store ASO desteği isteniyorsa ayrı kalem olur. Sürekli akış modeli kuran müşteriler için aylık abonelik benzeri sabit paket de tasarlayabiliyoruz; sprint başına ortalama key sayısı belli olduğunda öngörülebilir bütçe çıkar.
Net rakam için bir örnek dosyaya ve hedef dil listesine ihtiyacımız var; pilot bir dilde başlangıç teklifi 1-2 iş gününde dönüyor.