Android ve iOS Uygulama Yerelleştirmesi Arasındaki Farklar

Bir uygulamanın Türkçe sürümü hazırlanırken çoğu zaman tek bir metin dosyası düşünülür. Oysa aynı uygulamanın iki platform sürümü vardır ve bu sürümler metni aynı biçimde saklamaz. Android ve iOS uygulama yerelleştirmesi, çeviri açısından benzer, teknik açıdan ise belirgin biçimde farklı iki süreçtir.

İçindekiler

Jiménez-Crespo, çoğu ticari uygulamanın hem Android hem iOS sürümüyle sunulduğunu ve çeviri belleği kullanıldığında aynı belleğin paylaşılarak süreci hızlandırabildiğini belirtir (2024, s. 229). Yani ayrışma metinde değil, metnin bulunduğu kapta ve teslim biçimindedir.

Aşağıda iki platformun dosya yapısını, araçlarını ve teslim yollarını karşılaştırıyor; hangi kararların proje başında verilmesi gerektiğini gösteriyoruz.

İki ekosistem, iki geliştirme ortamı

Kitap, uygulamaların genellikle uluslararasılaştırma için tasarlanmış bir geliştirme ortamında üretildiğini ve Android Studio ile iOS tarafındaki Xcode gibi araçların yerelleştirilebilir ögeleri koddan ayırmayı kolaylaştıran işlevler içerdiğini yazar (Jiménez-Crespo 2024, s. 228).

Bu benzerlik yüzeyseldir. İki ortam da metni ayırır, ama farklı biçimlerde saklar. Android tarafında dizeler XML dosyalarında toplanır. Apple tarafında ise Xcode, yerelleştirme için metin dizelerini XLIFF dosyalarına ayırır (Jiménez-Crespo 2024, s. 229).

Bu fark tek başına büyük bir sorun değildir; çeviri araçları her iki biçimi de okur. Sorun, iki sürümün farklı zamanlarda ve farklı ekiplerce yönetilmesiyle başlar. Aynı düğme iki platformda farklı çevrilirse kullanıcı bunu fark eder.

Bazı projeler bu riski platformlar arası geliştirme ile azaltır. Kitap, tek bir ortamda geliştirilen bir çekirdek uygulamadan hem Android hem iOS sürümlerinin derlenebildiğini belirtir (2024, s. 228). Bu durumda metin de tek kaynaktan gelir.

Tek kaynak her sorunu çözmez. Platformların arayüz kalıpları farklıdır ve aynı cümle iki sistemde farklı bir bağlamda görünebilir. Bu yüzden ortak metin kullanılsa bile, sonuçların iki platformda ayrı ayrı gözden geçirilmesi gerekir.

Android tarafı: klasör adı hedef dili belirler

Android mantığı basittir ve klasör adına dayanır. Kaynak dildeki dizeler res/values klasöründeki strings.xml dosyasında bulunur. Her hedef dil için aynı adlı bir dosya, dil koduyla adlandırılmış yeni bir klasöre konur (Jiménez-Crespo 2024, s. 232).

Kitaptaki örnekte İngilizce dosya res/values-en, Fransızca dosya ise res/values-fr yolunda yer alır. Türkçe için karşılık res/values-tr olur. Sistem, cihazın dil ayarına bakarak doğru klasörü seçer; kod değişmez.

Bu yapının pratik sonucu şudur: yeni bir dil eklemek, yeni bir klasör açmaktan ibarettir. Dosyalar aynı dize adlarını taşıdığı sürece uygulama çalışır. Eksik bir dize varsa sistem kaynak dildeki karşılığa döner, yani uygulama çökmez ama karışık dilli görünür.

Bu sessiz geri dönüş, kalite kontrolü zorlaştıran bir özelliktir. Uygulama hatasız çalıştığı için eksik çeviri fark edilmez. Bu yüzden teslim öncesi kontrolde dize sayılarının kaynak ve hedef klasörlerde eşleşip eşleşmediğine bakmak gerekir.

Kitap ayrıca uygulamanın tersine derlenebildiğini ve çözülen dosya yapısında res klasörü içindeki values klasöründe strings.xml dosyasının bulunduğunu anlatır (Jiménez-Crespo 2024, s. 232). Bu yol, kaynak dosyalara erişimi olmayan projelerde kullanılır.

iOS tarafı: yerelleştirme kataloğu

Apple tarafında süreç bir katalog üzerinden yürür. Kitap, hedef diller seçildikten sonra Xcode’un .xcloc uzantılı bir yerelleştirme kataloğu klasörü oluşturduğunu ve her dil için yerelleştirilebilir kaynakların bu klasörde XLIFF dosyaları hâlinde bulunduğunu anlatır (Jiménez-Crespo 2024, s. 236).

Akış dışa aktarma ve içe aktarma üzerine kuruludur. Proje geliştirme dilindeki dizeleri XLIFF olarak dışa aktarır, dosyalar çevrilir ve tekrar projeye alınır. Ardından uygulama derlenir. Bu döngü, çeviri tarafında düzenli ve izlenebilir bir yapı sağlar.

Katalog klasöründe yalnızca metin bulunmaz. Kitap, katalog hakkında üstveri taşıyan bir JSON dosyasının ve çevirmenler için ekran görüntüsü ya da video içerebilen bir notlar klasörünün de yer alabildiğini belirtir (2024, s. 236). Bu notlar bağlam sorununu doğrudan azaltır.

Katalog yaklaşımının avantajı, her dilin kendi klasöründe tam bir paket olarak durmasıdır. Bir dilin teslimi geciktiğinde diğerleri etkilenmez. Dezavantajı ise dışa aktarma ile içe aktarma arasında geçen sürede kaynak metnin değişebilmesi ve iki sürümün ayrışmasıdır.

Android ve iOS uygulama yerelleştirmesi: karşılaştırmalı özet

İki platformun temel farklarını tek tabloda görmek, proje planı hazırlarken işi kolaylaştırır. Aşağıdaki özet kitabın ilgili bölümlerinden derlenmiştir.

Konu	Android	Apple iOS
Geliştirme ortamı	Android Studio	Xcode
Metin dosyası biçimi	XML (strings.xml)	XLIFF
Dil ayrımı	values-XX klasörü	.xcloc kataloğu
Görsel klasörü	res/drawable-XX	Katalog içindeki kaynaklar
Arayüz dosyaları	res/layout, res/menu	.xib ve .storyboard
Uygulama paketi	.APK	.APP

Tablo, aynı işin iki farklı biçimde paketlendiğini gösterir. Çeviri talebi hazırlarken hangi sütunda olduğunuzu belirtmek, teslim sonrası sürprizleri azaltır. Kapsam belirleme konusunda bilgi merkezimizdeki yazılar yardımcı olabilir.

Görseller ve arayüz dosyaları

Metin dosyaları buzdağının görünen kısmıdır. Android tarafında yerelleştirilecek görseller res/drawable klasöründe durur ve dil koduyla adlandırılmış eşlerine kopyalanır. Kitap, varsayılan logonun res/drawable klasöründe, İtalyanca sürümün ise res/drawable-it klasöründe bulunacağını örnekler (2024, s. 234).

Aynı bölümde res/layout, res/menu ve res/values/colors.xml gibi klasörlerin de yerelleştirme açısından ilgi çekici olduğu belirtilir. Yani yerleşim ve renk kararları da dile göre değişebilir. Bu, çevirinin ötesinde bir tasarım kararıdır.

Apple tarafında karşılık, arayüz dosyalarıdır. Kitap, Xcode kullanıldığında yerelleştirilecek metnin .xib ve .storyboard uzantılı arayüz dosyalarında da bulunduğunu ve bunların uygulamanın açılış ekranını kapsadığını yazar (2024, s. 237). Açılış ekranı unutulursa kullanıcının gördüğü ilk kare yabancı dilde kalır.

Aynı dize, iki farklı değişken gösterimi

Platform farkının en ince ayrıntısı değişken gösterimidir. Kitap, aynı selamlama dizesinin Android tarafında bir biçimde, iOS tarafında başka bir biçimde yazıldığını ve bazı bulut platformlarının bu farkı çevirmene tek bir ortak gösterimle sunduğunu anlatır (Jiménez-Crespo 2024, s. 229).

Dışa aktarma sırasında her dosya kendi doğru gösterimini geri alır. Çevirmen tek bir biçimle çalışır, sistem dönüşümü üstlenir. Bu düzenek olmadığında aynı cümlenin iki sürümü ayrı ayrı çevrilir ve hata ihtimali ikiye katlanır.

Aynı platformlarda benzer dizelerin yalnızca bir kez gösterilmesini sağlayan yineleme işlevleri de bulunur (2024, s. 229). İki platformun ortak metinlerinde bu işlev ciddi zaman kazandırır, çünkü örtüşme oranı genellikle yüksektir.

Böyle bir düzenek yoksa en azından bir kontrol adımı eklenmelidir. Çeviri tamamlandıktan sonra iki platformun dosyaları yan yana konup değişken sayıları karşılaştırılır. Eksik ya da fazla bir değişken, uygulamada çalışma anında hata olarak görünebilir.

Teslim yolu: dosya mı, uygulamanın kendisi mi?

Kitap iki teslim yolu tanımlar. Birincisinde müşteri dışa aktarılmış dosyaları doğrudan ya da bir bulut platformu üzerinden gönderir. İkincisinde uygulamanın tamamı APK veya APP dosyası olarak teslim edilir (Jiménez-Crespo 2024, s. 228).

İkinci yol daha fazla teknik yetkinlik ister. Uygulamanın açılması, kaynak klasörlerinin bulunması ve çeviri sonrasında yeniden derlenip imzalanması gerekir. Kitap, dilsel kalite kontrolü tamamlandıktan sonra APK dosyasının derlenip imzalanabildiğini ve ardından işlevsel testin başladığını belirtir (2024, s. 234).

Alıcı taraf için pratik sonuç şudur: teslim yolu, fiyatı ve süreyi doğrudan etkiler. Yalnızca dize dosyası gönderen bir proje ile tüm uygulamayı gönderen bir proje aynı işi tanımlamaz. Kapsamı baştan netleştirmek iki taraf için de korumadır.

Kitap ayrıca uygulama yerelleştirmesine özel araç sayısının yazılım yerelleştirmesine göre daha az olduğunu aktarır (Jiménez-Crespo 2024, s. 229). Bu, tedarikçi seçerken araç yelpazesinin dar olabileceği anlamına gelir; hangi araçla çalışıldığını sormak yerinde olur.

Türkiye bağlamı

Türkiye pazarında Android cihazların payı yüksektir, ancak iOS kullanıcıları uygulama içi harcamada belirgin biçimde öne çıkar. Bu ikilik, bütçe sınırlıyken hangi platformun önce yerelleştirileceği sorusunu gerçek bir karara dönüştürür. Cevap uygulamanın gelir modeline göre değişir.

Dil kodu tarafında dikkat edilecek bir ayrıntı vardır. Türkçe için kullanılan kod tr, bölgeli biçimiyle tr-TR olarak yazılır. Klasör adları ve katalog kayıtları bu kodla eşleşmezse cihaz Türkçe kaynakları hiç görmez ve uygulama İngilizce açılır.

Üçüncü konu büyük harf dönüşümüdür. Türkçede noktalı ve noktasız i harflerinin büyük harf karşılıkları farklıdır. Platform kütüphaneleri dil ayarını dikkate almazsa düğme etiketleri yanlış yazılır. Bu, iki platformda da ayrıca test edilmesi gereken bir davranıştır.

Son olarak yerel mevzuat vardır. Kişisel veri işleyen uygulamalarda aydınlatma metinlerinin Türkçe sunulması beklenir. Bu metinler arayüz dizeleriyle aynı dosyada tutulabilir, ancak hukuki onay süreci ayrıdır ve genellikle daha uzun sürer.

Bu sizin için ne anlama geliyor?

İki platformlu bir uygulamanız varsa, tek bir çeviri siparişiyle iki sürümü birden kapatmayı hedefleyin. Bu mümkündür, ama planlama ister. Aşağıdaki sıra çoğu projede işe yarar.

1. İki platformun dize listelerini karşılaştırıp ortak metinleri işaretleyin.
2. Ortak metinler için tek bir çeviri belleği ve terim listesi kurun.
3. Değişken gösterim farkını platform ya da araç düzeyinde otomatik eşleyin.
4. Görsel ve arayüz dosyalarını dize listesinden ayrı bir kalem olarak sayın.
5. Teslim yolunu (dosya mı, uygulama paketi mi) teklif aşamasında netleştirin.
6. Dil kodu ve büyük harf davranışını her iki platformda ayrı test edin.

Bu listeyi kendi projenize uyarlarken kapsamı yazılı hâle getirmeniz yeterli. Uygulama yerelleştirmesi için teklif isteyebilir, sorularınızı iletişim sayfamızdan iletebilirsiniz.

Sık sorulan sorular

Android ve iOS için ayrı çeviri yapmak gerekir mi?

Metin çoğunlukla aynıdır ve çeviri belleği paylaşılabilir. Farklı olan dosya biçimi, klasör yapısı ve değişken gösterimidir. Yani çeviri değil, paketleme ayrışır.

Android dizeleri hangi dosyada tutulur?

Kaynak metin res/values klasöründeki strings.xml dosyasındadır. Her hedef dil için values-tr gibi ayrı bir klasör ve aynı adlı bir dosya oluşturulur.

iOS tarafında hangi biçim kullanılır?

Xcode, seçilen hedef diller için .xcloc uzantılı bir yerelleştirme kataloğu klasörü oluşturur. Yerelleştirilecek kaynaklar bu klasörde XLIFF dosyaları hâlinde bulunur.

Uygulamanın tamamı çeviri için gönderilebilir mi?

Evet. Kitap iki yol tanımlar: dışa aktarılmış dosyaların gönderilmesi ya da uygulamanın APK veya APP dosyası olarak teslim edilmesi. İkinci yolda geliştirme araçlarını iyi bilmek gerekir.

Kaynaklar

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, s. 228–237.
• Android Developers, Localization Guide ve Translations Editor belgeleri (2024).
• Apple Developer, Exporting Localizations belgeleri (2024).