Mobil Uygulama Nasıl Yerelleştirilir

OpenL Team 3/14/2026

TABLE OF CONTENTS

Mobil uygulama yerelleştirme konusunda araştırma yapıyorsanız, genellikle “çeviri ipuçları”na ihtiyacınız yoktur. İhtiyacınız olan şey; uygulama dizelerini, düzeni, çoğul kuralları, sağdan sola desteği, ekran görüntülerini ve mağaza meta verilerini ürünü bozmadan kapsayan, yayına hazır bir iş akışıdır.

İşte temel fark burada yatıyor: mobil uygulama yerelleştirme sadece metin çevirmek değildir. Uygulamayı, ürün sayfasını ve QA sürecini her hedef pazar için uyarlamaktır. Apple, App Store’un 175 bölge ve 40 dilde kullanılabilir olduğunu belirtirken, Android 13 sistem düzeyinde uygulama bazında dil tercihlerini kullanıma sunmuştur. Başka bir deyişle, her iki büyük platform da artık dil seçimini sonradan eklenen bir özellik değil, temel bir ürün deneyimi olarak kabul etmektedir.

Bu rehber, iOS ve Android ekipleri için pratik adımları ele almaktadır.

Bir bakışta:

  • Uygulama içi yerelleştirmeyi App Store ve Google Play yerelleştirmesinden ayırın.
  • Herhangi bir çeviri yapmadan önce dizeleri dışsallaştırın.
  • Çoğul yapıları, değişkenleri, tarihleri, para birimlerini ve RTL desteğini erken aşamada ele alın.
  • Gerçek çevirileri göndermeden önce sözde dillerle (pseudolanguages) test edin.
  • Sadece açıklamaları değil, ekran görüntülerini ve mağaza varlıklarını da yerelleştirin.

Mobil Uygulama Yerelleştirme Gerçekte Neleri Kapsar

Yerelleştirme çalışmaları genellikle iki ana kola ayrılır.

1. Uygulama içi yerelleştirme

Bu, ürünün kendisidir:

  • Arayüz dizeleri
  • Hata mesajları ve kullanıma başlama metinleri
  • Tarihler, saat, sayılar, para birimi ve birimler
  • Çoğul ve cinsiyete duyarlı dizeler
  • Düzen genişlemesi ve sağdan sola davranışı
  • Metin veya yönsel anlam içeren görseller veya simgeler

Apple, uygulamaları küresel pazarlara hazırlamak için Xcode, Foundation API’leri, Auto Layout, Unicode desteği, yerelleştirilmiş varlık katalogları ve yön duyarlı sembollerin kullanılmasını açıkça önerir. Android da benzer şekilde, sabit kodlanmış metin ve konumlandırma yerine yerel ayar duyarlı kaynaklar, uygulama dili desteği ve RTL duyarlı düzenler önerir.

2. Mağaza listesi yerelleştirme

Kullanıcıların uygulamanızı keşfetme şekli budur:

  • Uygulama adı
  • Alt başlık veya kısa açıklama
  • Tam açıklama
  • Anahtar kelimeler
  • Ekran görüntüleri
  • Uygulama önizlemeleri veya tanıtım videoları

Bunu ayrı bir teslimat olarak değerlendirin. İyi yerelleştirilmiş bir uygulama, ürün sayfası genel, çevrilmemiş veya hedef pazar için görsel olarak uyumsuzsa yine de düşük performans gösterebilir.

Çeviriyle Değil, Uluslararasılaştırmayla Başlayın

Çeviri, yapıyla başlayan bir sürecin son adımıdır.

Dizeleri dışsallaştırın ve eksiksiz bir yedek yerel ayar tutun

Android’de Google, varsayılan res/values/strings.xml dosyanızın uygulamanızın ihtiyaç duyduğu her dizeyi tanımlaması gerektiği konusunda uyarır. Varsayılan dosya eksikse ve cihaz desteklenmeyen bir yerel ayarda çalışıyorsa, uygulama yüklenemeyebilir ve Zorla Kapat düğmesi içeren bir hata gösterebilir. Bu nedenle yerelleştirme, dil seçimiyle değil kaynak dosyası düzeniyle başlar.

iOS için Apple, kullanıcının görebildiği metin ve görsellerin çalıştırılabilir koddan ayrılmasını önerir; böylece bunlar kaynak dosyaları olarak yerelleştirilebilir. Modern Apple iş akışlarında, dize katalogları, Xcode 15 ve sonrasında çoğul içeren dizeler için önerilen yaklaşımdır.

Pratik kural:

  • Arayüz metnini asla görünümlere veya denetleyicilere sabit kodlamayın
  • Tek bir kanonik kaynak dili tutun
  • Her kullanıcıya yönelik dizenin sabit bir anahtarı, bağlamı ve yedeği olduğundan emin olun
  • Belirsiz dizeler için çevirmen yorumları ekleyin

Küçük bir örnek bunu daha iyi anlamanızı sağlayacaktır.

Android genellikle varsayılan bir strings.xml dosyasıyla başlar:

<!-- Primary CTA on the checkout screen. Keep it short. -->
<string name="checkout_cta">Pay now</string>
<string name="welcome_title">Welcome back, %1$s</string>

Ardından arayüzünüz İngilizce sabit kodlamak yerine kaynağı okur:

Text(text = stringResource(R.string.checkout_cta))

Apple platformlarında Xcode 15+ genellikle aynı fikri bir dize kataloğunda yönetir. Basitleştirilmiş bir Localizable.xcstrings örneği şöyle görünebilir:

{
  "sourceLanguage": "en",
  "strings": {
    "Pay now": {
      "localizations": {
        "en": { "stringUnit": { "value": "Pay now" } },
        "fr": { "stringUnit": { "value": "Payer maintenant" } }
      }
    }
  }
}

Dosya biçimini ezberlemenize gerek yok. Operasyonel ders daha basittir: kullanıcının görebildiği her dizenin tek bir doğruluk kaynağına, çevirmenler için yeterli bağlama ve bir yerel ayar eksik olduğunda güvenli bir yedeğe ihtiyacı vardır.

Uygulamanız ayrıca yapılandırılmış dil dosyaları gönderiyorsa, 2026’nın En İyi JSON Çevirmenleri rehberimiz otomasyon ve biçim koruma konusunda düşünmenize yardımcı olabilir.

Uygulama kaynak dosyaları için doğrudan bir araç seçeneği istiyorsanız, OpenL JSON Translator incelemeye değer. Anahtarları veya yapıyı bozmadan .json dosyalarını çevirmek için tasarlanmıştır; bu tam olarak uygulama dizeleri makine tarafından okunabilir yerelleştirme dosyalarında saklandığında ihtiyacınız olan şeydir. İş akışı basittir: uygulamanızdan, CMS’nizden veya yerelleştirme hattınızdan dışa aktarılan JSON’u yükleyin, hedef dili seçin ve aynı yapıya sahip çevrilmiş bir JSON dosyası indirin. Ürün sayfasına göre 100’den fazla dili ve 50 MB’a kadar dosyaları destekler, bu da onu yapılandırılmış içerikle uğraşan uygulama yerelleştirme ekipleri için pratik bir ilk geçiş aracı yapar.

Uygulama düzeyinde dil seçimini destekleyin

Kullanıcılar giderek artan bir şekilde uygulama dilini cihaz dilinden bağımsız olarak seçmeyi beklemektedir.

Apple platformlarında kullanıcılar, bir uygulama için tercih ettikleri dili cihaz dilinden bağımsız olarak seçebilir. Android’de Android 13, merkezi bir uygulama dili ayarı eklemiştir ve Google, otomatik uygulama bazında dil desteğini etkinleştirmeyi veya seçicinizi resmi API’lere bağlamayı önerir.

Bu gerçek ürünler için önemlidir. İki dilli ve çok dilli kullanıcılar telefonlarını İngilizce tutabilir ancak bir alışveriş, bankacılık veya teslimat uygulamasını başka bir dilde tercih edebilir. Uygulamanız tek bir dil modeli dayatıyorsa, çeviri kalitesi bir soru haline gelmeden önce sürtünme yaratıyorsunuz demektir.

Platform yerelleştirme yığınını kullanın

Gerçekten ihtiyacınız olmadıkça paralel bir yerelleştirme sistemi icat etme dürtüsüne karşı koyun.

Çoğu ekip için varsayılan platform yığını yeterlidir:

  • iOS: dize katalogları, Localizable.strings, .stringsdict, Foundation biçimlendiricileri, Auto Layout
  • Android: res/values/, yerel ayara özgü kaynak klasörleri, LocaleConfig, setApplicationLocales(), supportsRtl

Özel yerelleştirme altyapısı çok büyük ölçekte mantıklıdır, ancak operasyonel yük ekler. Yerel sistemle başlayın, ardından yalnızca gerçek bir sorun yaşadığınızda genişletin.

Çoğu Ekibin Gözden Kaçırdığı Kısımları Yerelleştirin

Ekipler genellikle görünür cümleleri çevirir ve etraflarındaki ürün mekaniklerini gözden kaçırır.

Çoğullar, değişkenler ve dilbilgisi

Çoğul kuralları evrensel değildir. Unicode CLDR çoğul kuralları zero, one, two, few, many ve other gibi kategoriler tanımlar ve farklı diller farklı alt kümeler kullanır. Apple, eski .stringsdict iş akışlarında other’ın tek zorunlu kategori olduğunu belirtir, ancak dile özgü kategorileri atlamak yine de dilbilgisi açısından yanlış çıktı üretebilir. Android ve iOS’un her ikisi de yerel ayar duyarlı çoğul işlemeye bir nedenden dolayı güvenir.

Naif makine çevirisinin başarısız olduğu yer burasıdır:

  • 1 file ile 2 files İngilizce’de kolaydır
  • Slav dilleri genellikle ikiden fazla çoğul biçime ihtiyaç duyar
  • Bazı diller isimleri, fiilleri veya çevresindeki kelimeleri birlikte değiştirir

Asla "You have " + count + " messages" gibi parçalar birleştirerek çoğullaştırılmış arayüz oluşturmayın. Bunun yerine platform çoğul kaynaklarını kullanın.

Her platformda bunun minimal yapısı şöyledir.

Android:

<plurals name="files_remaining">
  <item quantity="one">%1$d file remaining</item>
  <item quantity="other">%1$d files remaining</item>
</plurals>
Text(text = pluralStringResource(R.plurals.files_remaining, count, count))

iOS eski .stringsdict örneği:

<plist version="1.0">
<dict>
  <key>%#@files@</key>
  <dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@files@</string>
    <key>files</key>
    <dict>
      <key>NSStringFormatSpecTypeKey</key>
      <string>NSStringPluralRuleType</string>
      <key>NSStringFormatValueTypeKey</key>
      <string>d</string>
      <key>one</key>
      <string>%d file remaining</string>
      <key>other</key>
      <string>%d files remaining</string>
    </dict>
  </dict>
</dict>
</plist>

Xcode 15 ve sonrasında Apple, çoğulları dize kataloglarında yönetmeyi önerir, ancak ilke aynı kalır: platforma bir mesaj kalıbı verin ve doğru dil biçimini seçmesine izin verin.

Yer tutucular ve yapılandırılmış dizeler etrafında daha derin iş akışı güvenceleri için Kodu Bozmadan Teknik Belgeleri Nasıl Çevirirsiniz makalesine bakın.

Tarihler, sayılar, para birimi ve birimler

Apple, yerel ayarlar arasında tarihleri, uzunlukları, ağırlıkları, fiyatları ve para birimi simgelerini biçimlendirmek için Foundation API’lerinin kullanılmasını açıkça önerir. Aynı ilke Android için de geçerlidir: noktalama işaretlerini, ondalık ayırıcıları veya birim sıralamasını sabit kodlamak yerine verileri yerel ayar duyarlı API’lerle biçimlendirin.

Tipik başarısızlıklar şunlardır:

  • 03/04/2026’nın farklı bölgelerde farklı şeyler ifade etmesi
  • USD dışı pazarlar için sabit kodlanmış dolar işaretleri
  • 1,234.56’nın ondalık ayırıcı olarak virgül kullanan yerel ayarlarda yanlış görüntülenmesi
  • Ölçü birimlerinin yanlış sistemde gösterilmesi

Uygulamanız zamanlama, faturalandırma, teslimat zaman aralıkları veya analitik içeriyorsa, bu yerelleştirmenin bir parçasıdır, cilalama değil.

Düzen genişlemesi ve sağdan sola desteği

İngilizce genellikle kompakttır. Almanca daha uzundur. Arapça ve İbranice okuma yönünü tersine çevirir. İngilizce’de düzgün görünen bir düzen diğer yerel ayarlarda ciddi şekilde bozulabilir.

Apple, gerçek çevirileri içe aktarmadan önce bile sağdan sola sözde dili ve çift uzunluklu sözde dil dahil olmak üzere sözde dillerle test yapılmasını önerir. Android, left ve right yerine start ve end kullanılmasını, android:supportsRtl="true" etkinleştirilmesini ve RTL düzenlerinin cihaz üzerinde Force RTL ile test edilmesini önerir.

Buradaki kontrol listeniz basittir:

  • Düğmelerin ve etiketlerin büyümesine izin verin
  • Önemli arayüz öğeleri için sabit genişlikli metin kapsayıcılarından kaçının
  • Yönsel arayüzü uygun yerlerde aynalayın
  • RTL’de simgeleri, ok işaretlerini, ilerleme akışlarını ve karuselleri doğrulayın
  • Latince ürün adları veya kupon kodları içeren Arapça arayüz gibi karışık yönlü metni test edin

Görseller, simgeler, ekran görüntüleri ve video

Apple’ın yerelleştirme kılavuzu birçok ekibin gözden kaçırdığı önemli bir noktaya değinir: görseller de yerelleştirilebilir. Bu, görsel setlerini, sembol setlerini ve özel semboller için yönselliği kapsar. Ekran görüntünüz İngilizce arayüz, afişlerde İngilizce metin veya soldan sağa oklar içeriyorsa, ekran görüntüsünün kendisi yerelleştirilmemiş demektir.

Bu özellikle kullanıma başlama ekranları, eğitim kartları ve App Store varlıkları için önemlidir. Kullanıcılar “pazarlama görselleri”ni “ürün dili”nden zihinsel olarak ayırmaz. Deneyimi bir bütün olarak değerlendirirler.

App Store ve Google Play Sayfalarınızı Ayrı Olarak Yerelleştirin

Uygulama içi çalışmayı iyi yaptıktan sonra bile birçok ekibin yükleme kaybettiği yer burasıdır.

Planlanması gereken App Store gereksinimleri

Apple, uygulama açıklaması, anahtar kelimeler, uygulama önizlemeleri ve ekran görüntüleri dahil olmak üzere App Store Connect’teki meta verilerin yerelleştirilmesini önerir. Apple ayrıca ürün sayfanızda 10’a kadar ekran görüntüsü ve desteklenen her cihaz boyutu ve dil için 3’e kadar uygulama önizlemesi gösterebileceğinizi belirtir. Uygulama önizlemeleri 30 saniyeye kadar olabilir ve önizleme olmadığında ekran görüntüleri daha da önemlidir çünkü ilk bir ila üç ekran görüntüsü arama sonuçlarında görünebilir.

Bunun iki sonucu vardır:

  1. İlk ekran görüntüleriniz sadece belgeler değil, keşfedilebilirlik varlıklarıdır.
  2. Her yerde İngilizce varlıkları yeniden kullanmak yerine, öncelikli pazarlar için ekran görüntülerini ve önizlemeleri yerelleştirmelisiniz.

Planlanması gereken Google Play gereksinimleri

Google Play, listeleme yerelleştirmesini kendi iş akışı olarak ele alır. Play Console, yerelleştirilmiş metin, hedef dilde ekran görüntüleri ve yerelleştirilmiş grafik varlıkları eklemenize olanak tanır. Yerelleştirilmiş grafik varlıkları olmadan metin çevirileri eklerseniz, Google varsayılan dildeki görsellerin yine de gösterileceğini belirtir.

Google ayrıca, kendi mağaza listesi çevirilerinizi eklemezseniz kullanıcıların otomatik olarak oluşturulduğuna dair bir bildirimle birlikte otomatik bir çeviri görebileceğini belirtir. Bu bir yedek olarak faydalıdır, ancak güçlü bir pazar giriş stratejisi değildir.

Özellikle ilgili güncel bir özellik: Play Console, Gemini modelleri kullanarak uygulama dizelerini ücretsiz olarak sürekli çevirebileceğinizi belirtir. Daha spesifik olarak Google, bunun taslak sürümlere yüklenen uygulama paketlerindeki strings.xml dosyasından gelen uygulama dizelerine uygulandığını ve oluşturulan çevirileri yayınlamadan önce yerleşik bir emülatörde önizleyebileceğinizi söyler. Bu, ilk geçiş kapsamını hızlandırmanın güçlü bir yoludur, ancak kritik akışlar için yine de insan incelemesiyle takip edilmelidir.

Bir Yayın ve QA İş Akışı Oluşturun

İyi bir yerelleştirme süreci, daha hızlı çevirmekten çok daha az sürprizle göndermekle ilgilidir.

Adım 1. Hedef yerel ayarları bilinçli olarak seçin

“Her şeyi 20 dile çevir” ile başlamayın.

Şunlarla başlayın:

  • Mevcut indirme dağılımınız
  • Aktif olarak desteklediğiniz ülkeler
  • Faturalandırma, hukuki ve müşteri desteği kapsamı
  • Hem uygulamayı hem de mağaza listesini birlikte yerelleştirebilip yerelleştiremeyeceğiniz

Bir pazarı uçtan uca göndermek genellikle beş pazarı yarım yamalak göndermekten daha iyidir.

Adım 2. Yerelleştirmeye hazır varlıklar oluşturun

Çeviri başlamadan önce dondurun ve hazırlayın:

  • Bağlam içeren kaynak dizeler
  • Yerel ayara göre ekran görüntüsü listesi
  • Sözlük ve ürün adı kuralları
  • Yer tutucu kuralları
  • Mağaza metni için karakter sınırı rehberliği
  • Yerel ayara özgü inceleme sahipleri

Uygulama ayrı depolar veya birden fazla dosya biçimi kullanıyorsa, adlandırma ve çıkarma işlemlerini erken standardize edin.

Adım 3. Önce sözde yerelleştirmeyle test edin

Apple platformlarında çift uzunluklu ve sağdan sola sözde dillerini kullanın. Android’de desteklenmeyen yerel ayarları, Force RTL’yi ve uygulama dili ayarlarını test edin. Bu şunları yakalar:

  • Kesilmiş düğmeler
  • Kırpılmış başlıklar
  • Gizli metin
  • Yanlış hizalama
  • Yerelleştirilmemiş dizeler
  • Sabit kodlanmış sol/sağ varsayımları

Bu, yapabileceğiniz en ucuz QA geçişlerinden biridir.

Adım 4. Gerçek cihazlarda dilbilimsel QA çalıştırın

Çeviriler geldikten sonra:

  • Her hedef dilde kritik akışları test edin
  • Sistem dili ve uygulama dili davranışını karşılaştırın
  • Çoğul davranışını ve yer tutucuları doğrulayın
  • Ödemeleri, tarihleri ve adresleri kontrol edin
  • Ekran görüntülerini ve mağaza listelerini hedef pazarda inceleyin

Bir hata kullanıma başlama, ödeme, kimlik doğrulama veya bildirimleri etkiliyorsa, bunu bir yayın engelleyici olarak değerlendirin.

İlk yerelleştirme sprint kontrol listesi

Bu ilk ciddi dağıtımınızsa, sprinti temiz bir şekilde bitirebilecek kadar küçük tutun:

  • 10 değil, 1 hedef yerel ayar seçin.
  • Bir yayın dalı için kaynak dizeleri dondurun.
  • Tüm kullanıma başlama, ödeme, hesap ve bildirim dizelerini bağlam yorumlarıyla dışa aktarın.
  • App Store ve Google Play için yerelleştirmek istediğiniz ekran görüntülerini yakalayın.
  • Gerçek metni çevirmenlere göndermeden önce bir sözde yerelleştirme geçişi çalıştırın.
  • Uygulama dizelerini ve mağaza listesi metnini aynı sprintte çevirin.
  • Çevirileri yeniden içe aktarın ve hem iOS hem de Android’de uygulama dili geçişini test edin.
  • En önemli 5 kullanıcı yolculuğunu gerçek cihazlarda QA yapın.
  • Aynı yerel ayar için ekran görüntülerini, uygulama önizlemelerini ve mağaza meta verilerini güncelleyin.
  • Önce TestFlight’a veya dahili bir kanala gönderin, ardından destek taleplerini ve çökme raporlarını izleyin.

Bu kontrol listesi bilinçli olarak dardır. Temiz bir uygulama deneyimi ve senkronize mağaza varlıklarıyla tek bir yerel ayar, birçok pazarda aceleye getirilmiş bir lansmandan çok daha fazlasını öğretir.

Gerçek Dünya Örnekleri

Yukarıdaki temel fikirler teorik değildir.

DoorDash çeviriyi bir platform sorunu olarak inşa etti

2022’de DoorDash, dört dilde bir milyondan fazla dizeyi zaten çevirdiğini ve yeni dil ekleme sürecini saatlerce süren geliştirici çabasından bir dakikada tek bir komuta indirdiğini belirtti. İlginç olan ders sadece ölçek değil, yapıdır: DoorDash statik ve dinamik dizeleri ayırdı, sözlük ve stil kılavuzu desteği ekledi ve çevrilmemiş dizelerin sızmasını önlemek için güvenceler inşa etti.

2 Şubat 2026 tarihli bir DoorDash blog yazısında şirket, yeniden inşa edilen kullanıma başlama platformunun artık tüm DoorDash pazarlarında kayıtları yönettiğini ve sorunsuz yerelleştirme ile hızlı uluslararası lansmanları desteklediğini belirtti. Olgun yerelleştirme tam olarak böyle görünür: yeniden kullanılabilir iş akışları, bölgesel esneklik ve daha az tek seferlik geçici çözüm.

Meta yerelleştirmeyi hem bir dil sorunu hem de bir uygulama boyutu sorunu olarak ele aldı

Meta, Android için Facebook kullanıcılarının yaklaşık %57’sinin ve iOS için Facebook kullanıcılarının %49’unun uygulamayı İngilizce dışında bir dilde kullandığını söylüyor. Aynı yazıda Meta, paketlenmiş çeviri dosyalarının kaldırılmasının iOS uygulamasında 16,6 MB’a kadar tasarruf sağladığını ve Android’in uygulama boyutunu artırmadan neredeyse bir düzine daha fazla dil eklemesine olanak tanıdığını belirtiyor.

Çıkarılacak ders daha küçük ekipler için bile faydalıdır: yerelleştirmenin mühendislik sonuçları vardır. İkili dosya boyutunu, çalışma zamanı yüklemeyi, çeviri dağıtımını ve yayın mekaniklerini etkiler, sadece metin yazarlığını değil.

Göndermeden Önce Son Kontrol Listesi

Bunu son bir geçiş olarak kullanın:

  • Kullanıcının görebildiği tüm dizeler dışsallaştırılmış.
  • Varsayılan yedek kaynaklar eksiksiz.
  • Çoğullar ve yer tutucular platform yerel yerelleştirme desteğini kullanıyor.
  • Tarihler, saat, sayılar, para birimleri ve birimler yerel ayar duyarlı.
  • RTL düzenleri ve karışık yönlü metin test edilmiş.
  • Mağaza listesi metni hedef pazarlar için yerelleştirilmiş.
  • Ekran görüntüleri ve önizlemeler öncelikli diller için yerelleştirilmiş.
  • Uygulama içi dil seçimi iOS ve Android’de beklendiği gibi çalışıyor.
  • Dilbilimsel QA en önemli kullanıcı yolculuklarını kapsamış.

Son Düşünceler

Mobil uygulama yerelleştirmesini düşünmenin en basit yolu şudur: ürünü çevirin, deneyimi yerelleştirin ve yayını test edin.

Bunu ilk kez yapıyorsanız, ilk günden mükemmel küresel kapsam hedeflemeyin. Bir veya iki stratejik yerel ayar seçin, uygulamayı ve mağaza sayfasını birlikte yerelleştirin, ciddi bir QA geçişi çalıştırın ve gerçek kullanımdan öğrenin. Halihazırda kaynak dosyaları ve geliştiriciye yönelik içerik yönetiyorsanız, bu iş akışını Kodu Bozmadan Teknik Belgeleri Nasıl Çevirirsiniz ve 2026’nın En İyi JSON Çevirmenleri ile eşleştirin.

Bu hafta yalnızca bir adım atacaksanız, şunu yapın: 1 yerel ayar seçin, 1 sözde yerelleştirme geçişi çalıştırın ve 1 eşleşen App Store veya Google Play listesini yerelleştirin. Bu üç parçalı test, yirmi yerel ayarı paralel olarak çevirmekten hazırlığınız hakkında daha fazla şey söyleyecektir.

Uygulama metni, ekran görüntüleri veya yapılandırılmış dil dosyaları için hızlı bir ilk geçişe ihtiyacınız varsa, taslağı hızlandırmak için otomasyonu kullanın, ardından yayından önce insan QA adımını koruyun. Kullanıcı güvenini koruyan ve “çevrilmiş ama gerçekten yerelleştirilmemiş” bir lansman engelleyen kısım budur.

Kaynaklar