Web ve native UI için dayanıklı yerelleştirme iş akışı

Yerelleştirme yönetilmediğinde neler ters gider

Yönetilmeyen yerelleştirme genellikle önce küçük, sinir bozucu şekillerde başarısız olur, sonra daha pahalı sorunlara yol açar. Dün sığan bir etiket bugün taşar. Eksik bir anahtar ham bir tanımlayıcı olarak görünür. İngilizcede düzgün olan bir çoğul başka bir dilde yanlış veya kaba olabilir.

Çoğu ekip baskı altında aynı sorunları düzeltir:

• Kesilmiş butonlar, kırpılmış başlıklar veya metnin simgelerin üzerine taşması
• İngilizceye dönüşen veya anahtar adını gösteren eksik anahtarlar
• Yanlış çoğul formları (örneğin "1 items") ve cinsiyete bağlı dillerde bozuk dilbilgisi
• Aynı kavram için ekranlar arasında tutarsız ifadeler
• Bir ekran çevirisiz yayınlandığı için son dakika düzeltmeleri

Web ve native ekranlar genellikle farklı şekillerde başarısız olur. Web'de esnek düzenler sorunları ancak belli bir görüntüleme alanı veya tarayıcı ortaya çıkarana kadar gizleyebilir. Metin beklenmedik şekilde kayabilir, butonları itebilir veya bir ızgarayı bozabilir. Native uygulamalarda boşluklar daha katıdır. Uzun bir çeviri önemli öğeleri ekrandan itebilir, erişilebilirlik yazı tipi boyutlarıyla çarpışabilir veya bir bileşen otomatik yeniden boyutlandırmadığı için kırpılabilir.

Sağlam bir yerelleştirme iş akışı çoğunununu önler: anahtarları stabil yapar, çevirileri gözden geçirilebilir kılar ve UI kontrollerini rutin hale getirir. Bu, güncellemeleri daha az sürprizle göndermenize yardımcı olur. Düzgünleştiremeyeceği şey belirsiz kaynak metindir. Orijinal metin belirsizse (ör. bağlamı olmayan "Open" veya "Apply"), çeviri hâlâ bir tahmin olur.

Basit bir başarı tanımı "her şey çevrildi" değildir. Başarı şudur:

• UI web ve native ekranlarda okunabilir kalır
• Anahtarlar sürekli değişmediği için güncellemeler hızlıdır
• QA, kullanıcılar görmeden önce sorunları bulur

Örnek: bir sepet ekranı "{count} item(s)" gösteriyorsa, yönetilmemiş dizgiler garip çoğullar ve bozuk boşluklara yol açar. Yönetilen bir yaklaşım doğru çoğul kurallarını zorlar ve bir butonun Almanca'da %30 büyümeden önce yakalanmasını sağlar.

Sahipliği belirleyin ve tek bir gerçek kaynağı seçin

Bir yerelleştirme iş akışı en hızlı biçimde çökerken kimse şu soruyu yanıtlayamıyorsa: “Gerçek metin hangisi?” Metinler için tek bir gerçek kaynağı seçin ve bunu sıkıcı derecede net yapın. Bu kaynak bir repo dosyası, bir çeviri platformu veya dahili bir tablo olabilir, ama tartışmaları sonlandıran tek yer olmalıdır.

Rolleri işlere göre tanımlayın, iş unvanlarına göre değil. Birisi anlam ve tonu onaylamalı (genellikle Ürün veya Pazarlama). Birisi anahtarları stabil ve kodda kullanılabilir tutmalı (genellikle Mühendislik). Birisi UI kısıtlarını korumalı (genellikle Tasarım), özellikle web ve native ekranlar farklı davrandığında.

Çoğu çatışmayı önleyen bir ayrım:

• Anahtar oluşturan: ekranı gönderen kişi, UI yeni metin gerektirdiğinde yeni anahtar oluşturur.
• Metin onaylayıcısı: bir PM veya metin sahibi kaynak dili onaylar.
• Çeviri editörü: çevirmenler çevirileri değiştirebilir, ama anahtar adlarını yeniden adlandıramaz.
• Anahtar değişiklikleri: yalnızca anahtar sahibinin anahtarları emekliye ayırma veya birleştirme yetkisi vardır; nedenini belirten bir not eklenmelidir.

Sürümlerin tıkanmaması için yanıt süre beklentileri belirleyin. Örneğin: yeni anahtar istekleri 1 iş günü içinde onaylanır, kaynak metin onayı 2 gün içinde, kritik düzeltmeler (kırık UI, yanlış yasal metin) saatler içinde ele alınır.

Somut örnek: ekibiniz hem web hem de native ekranları olan yeni bir “Şifre sıfırlama” akışı oluşturur. Geliştirici anahtarları ekler, PM nihai İngilizce metni onaylar ve çevirmenler diğer dilleri doldurur. Bir çevirmen “Reset” kelimesinin “Change” olması gerektiğini fark ederse çeviriyi günceller, ama anahtar aynı kalır. PM metni ekranlar arasında yeniden kullanmak isterse, yapısal değişikliği yalnızca anahtar sahibi yapar ki hiçbir şey sessizce bozulmasın.

Anahtar stratejisi: yeniden kullanım, stabilite ve ekran sınırları

İyi bir yerelleştirme iş akışı tek bir kural ile başlar: anahtarlar tanımlayıcıdır, İngilizce cümle değil. Onları parça numarası gibi görün. Metni daha sonra değiştirirseniz, anahtar genellikle aynı kalmalıdır.

Anlam farklıysa yeni bir anahtar oluşturun. Anlam aynıysa, ekran farklı olsa bile bir anahtarı yeniden kullanın. Bir profil ekranındaki “Save” ile ayarlar ekranındaki “Save” her ikisi de “değişiklikleri kaydet” anlamındaysa aynı anahtar paylaşılabilir. Ama “Save” “yer imi ekle” anlamındaysa farklı bir anahtar olmalıdır; çünkü çevirmenlerin farklı bir fiile ihtiyacı olabilir.

Kısa UI etiketlerini uzun içerikten ayırın. Bir buton etiketi, bir yardımcı ipucu ve bir hata mesajı genellikle farklı şekilde çevrilir ve farklı uzunluk sınırlarına sahiptir. Bunları ayrı anahtarlar halinde tutmak tonu ve noktalama işaretini düzenlemeyi kolaylaştırır.

Ekran sınırları, aynı ifadeyi zorlamadan

Web ve native arasında yeniden kullanımı hedefleyin, ama platformlar farklı dil gerektiriyorsa bunu zorlamayın. Native bir izin istemi genellikle bir web ipucundan daha açık ve resmi metin gerektirir. Bu durumda aynı kavramı koruyun ama her platform için ayrı anahtar kullanın ki her UI doğal okunsun.

Pratik bir desen: anahtarları özellik ve UI türüne göre gruplayın, sonra bu sınırlar içinde yeniden kullanın:

• Anlam aynıysa aynı özellik içinde yeniden kullanın
• UI türüne göre anahtarları ayırın (etiket vs yardım vs hata vs sistem istemi)
• Sadece ifade farklı olmalıysa platform varyantları kullanın
• Anahtarları stabil tutun, sadece gösterilen metni değiştirin
• Göründüğü yer, karakter sınırları gibi bağlam notları ekleyin

Örneğin, aynı “Müşteriyi sil” eylemi web yönetici panelinde ve native saha uygulamasında olabilir. Çekirdek eylem etiketini yeniden kullanabilir, ama native onay metni daha güçlü uyarılar veya daha kısa satırlar gerektiriyorsa ayrı bir anahtar tutabilirsiniz.

Çeviri anahtarlarını adlandırma ve düzenleme

İyi bir adlandırma sistemi yerelleştirmeyi en iyi şekilde sıkıcı kılar. İnsanlar dizgileri hızlıca bulur, çevirmenler bağlamı görür ve anahtarlar metin değişse bile stabil kalır.

Nerede, ne olduğu, ne amaçla olduğu ve bir varyant olup olmadığı sorularını cevaplayan okunabilir bir konvansiyon kullanın. Web ve native ekranlarda işe yarayan basit bir desen:

<product_or_domain>.<screen_or_flow>.<component>.<purpose>[.<variant>]

Örneğin, bir müşteri portalında: portal.login.button.submit veya portal.orders.empty_state.title. Bu, anahtarları ekran veya akışa göre gruplayıp bileşenle aramayı kolaylaştırır.

Kötü anahtarlar ya çok belirsiz ya da mevcut İngilizce metne çok bağlıdır:

• İyi: portal.profile.field.email.label
• Kötü: emailText (kapsam yok, amaç yok)
• Kötü: please_enter_your_email (metin değişince kırılır)
• İyi: portal.checkout.error.payment_failed
• Kötü: error_12

Varyantlar belirgin olmalı, noktalama veya karışık yazım ile hile yapılmamalı. Sıkışık bir mobil başlık için daha kısa bir etiket gerekiyorsa varyant ekleyin: ...title.short vs ...title.long. Büyük/küçük harf farkları gerekiyorsa, platform metni güvenle dönüştüremezse ayrı anahtarlar tercih edin: ör. ...button.save ve ...button.save_titlecase.

Yer tutucular için de kurallar olmalı ki çevirmenler tahminde bulunmasın.

• İsmi verilmiş yer tutucular kullanın: {user_name}, {count}, {date}
• Hiçbir zaman birleştirmeyin: "Hello " + name gibi dizgiler kurmayın
• Birimlerin dil bağımlı olduğu yerlerde birimleri dizginin içinde tutun: {count} items değil {count} + " items"
• İzin verilen formatları tanımlayın: ISO tarihleri, para birimi veya platforma özgü tarih biçimleri
• Zor dizgiler için kısa not ekleyin (örneğin {count} sıfır olabilir mi?)

Çoğullaşma ve dilbilgisi kurallarıyla yeniden çalışmayı önleme

Çoğullaşma, iş akışlarının ilk kırıldığı yerdir. Birçok ekip her dilin yalnızca "bir" ve "birden çok" olduğunu varsayar, sonra UI yanlış veya son dakika düzeltmeleri gerektirir.

Dillerin birkaç çoğul kategorisi olabilir. İngilizce çoğunlukla "one" ve "other" kullanırken, Rusça, Lehçe, Arapça ve Çekçe gibi diller few, many veya zero gibi formlar kullanabilir. Erken dönemde tek bir model sabitleştirirseniz, daha sonra web ve native üzerinde dizgileri yeniden yazmak zorunda kalmazsınız.

Çoğul dizgiler için tek bir standart seçin ve her yerde (web, iOS, Android, backend-rendered metin) buna sadık kalın. Pratik bir yaklaşım, her form için ayrı anahtarlar yerine bir anahtar içinde çoğul formlar saklamaktır. Form setini CLDR kategorilerine dayandırmak gerçek dil kurallarıyla uyumlu olur.

Bir kural: UI cümlelerini "You have " + count + " messages" gibi parçalardan oluşturmayın. Kelime sırası değişebilir ve bazı diller sayıya bağlı olarak ekler veya farklı durumlar gerektirebilir.

Pratik bir anahtar deseni

Bir mesaj sayacı için bir stabil anahtar tanımlayın ve sayıyı parametre olarak verin. Sonra çevirmenlere her dil için gereken formları sağlayın.

• Kavram başına bir anahtar kullanın (örnek: inbox.message_count)
• CLDR formlarını destekleyin (zero, one, two, few, many, other)
• Her zaman yer tutucular kullanın (örnek: {count}) ve bunları tüm cümlenin içinde bırakın
• Anlam belirsizse çevirmen notu ekleyin (örneğin “messages” mı yoksa “unread messages” mı?)

Cinsiyet ve dilbilgisi hâlleri

Bazen çoğul kuralları yeterli olmaz. UI kişiye hitap ediyorsa ("Welcome, Alex") veya rollere atıf varsa ("assigned to him/her"), bazı diller farklı kelimeler gerektirir. Diğer diller belirli edatların ardından isimlerin hâlini değiştirir.

Böyle durumlarda, gerçekten farklı gramer gerektiren durumlar için ayrı dizgiler oluşturun, sadece stil farkı için değil. Hedef daha az anahtar değil, QA sırasında “doğru” çevrilen ama bağlamda yanlış duran çevirilerle daha az sürpriz almaktır.

Platformlar arası biçimlendirme ve düzen kısıtlamaları

Bir çeviri doğru olabilir ama yine de UI'i bozabilir. Web ve native uygulamalar metni farklı render ettiğinden iş akışınız biçimlendirme kuralları ve düzen kontrollerini içermelidir, sadece çevrilmiş dizgilere güvenmeyin.

Sayıları, paraları ve tarihleri nasıl görüntüleyeceğinizi standardize edin. "$" + amount gibi birleştirmeyin veya bir etikette tarih formatını sert kodlamayın. Yerel ayara duyarlı biçimlendirme kullanın ki ayırıcılar ve sıra beklentilere uysun (1,000.50 vs 1 000,50; gün-ay-yıl vs ay-gün-yıl). Saat dilimleri yaygın bir tuzaktır: zaman damgalarını UTC olarak saklayın, kullanıcı yerel saat diliminde formatlayın ve bir zamanın belirli bir bölgeye ait olduğunu açıkça belirtin (ör. mağaza teslim süresi).

Metin yönü sessizce bozabilir. Sağdan sola (RTL) dilleri destekliyorsanız, yansıtılmış düzenler ve değişen noktalama için plan yapın. Yön belirten simgeler (oklar, geri düğmeleri, ilerleme adımları) genellikle çevrilmelidir. RTL geçişini inceleme sürecine dahil edin, tam destek vermeseniz bile.

Mobilde yazı tipleri ve boşluklar webden daha fazla kayabilir. Web UI'de sığan bir dizgi SwiftUI veya Kotlin'de garip şekilde kayabilir. Güvenli bir minimum yazı tipi boyutu belirleyin, anlamlı yerlerde etiketlerin sarılmasına izin verin ve varsayılan yazı tipinizin kapsamadığı betikler için yedek fontlar tanımlayın.

Erişilebilirlik için yerelleştirilmiş kontroller de gerekir. Ekran okuyucular sayıları, kısaltmaları ve karışık dil metinlerini beklenmedik şekillerde okuyabilir.

Sorunların çoğunu önleyen düzen kılavuzları:

• Metin genişlemesine (%30–50) göre tasarım yapın ve sabit genişlikli butonlardan kaçının.
• Dinamik değerleri (sayım, fiyat, tarihler) ayrı formatlanmış tokenlar olarak tutun.
• Özel desenler yerine platforma özgü tarih ve sayı biçimlendiricilerini kullanın.
• Yayın öncesi en az bir RTL ve bir “uzun metin” yerel ayarını test edin.
• Temel akışlarda (giriş, ödeme, ayarlar) ekran okuyucu kontrolleri çalıştırın.

Örnek: "Toplam: $1,234.50" etiketi "1 234,50 €" haline gelebilir; simgenin değerden sonra gelmesi, farklı boşluk ve ekran okuyucuda "Toplam" ile miktar arasında uygun bir duraklama gerekebilir.

Yeni ekrandan yayına adım adım iş akışı

Yerelleştirme iş akışı çoğu ekibin beklediğinden daha erken başlamalıdır: ekran hâlâ tasarlanırken. UI 'tamam' olana kadar beklerseniz, çevirileri aceleyle yapar, kırpılmış metin gönderir veya "şimdilik" diye sabit metin koyarsınız.

Her etiket, buton ve mesaj tasarlanırken bir çeviri anahtarı ekleyerek başlayın. Temel dilde varsayılan metni yazın ve nerede göründüğü, ne yaptığı gibi kısa bağlam ekleyin. checkout.pay_button gibi bir anahtar, çevirmenlerin butonun fiil mi yoksa etiket mi olduğunu bilmediği sürece faydasızdır.

UI'i yer tutucular ve temel dil geri dönüşü ile uygulayın. Değişkenleri açık tutun ({name} veya {count} gibi) ve cümleleri birbirine eklemekten kaçının. Bu, diller arası dilbilgisini bozmanın en hızlı yollarından biridir.

Metinleri çeviri için gönderirken çevirmenlerin doğru olabilmesi için gerekenleri ekleyin: her ekran için bir ekran görüntüsü (veya metin değişiyorsa kısa bir video), sıkışık alanlar için karakter sınırları (sekme başlıkları, butonlar, rozetler), ton ve terminoloji notları ve dinamik yer tutucuların ne anlama geldiği listesi.

Çeviriler döndüğünde, erken birleştirin ve hem web hem native sürümlerini oluşturun. En yüksek riskli ekranlarda hızlı UI kontrolleri yapın: giriş, onboarding, ödeme ve ayarlar. Kesilmiş metin, üst üste binme, eksik anahtarlar ve yanlış çoğul formlar arayın.

Son olarak, yayınlayın ve izleyin. Eksik anahtarları, varsayılan dile dönüş olaylarını ve metnin sık taşma eğiliminde olduğu ekranları takip edin.

Çevirmenlere doğruluk için ihtiyaçları verin

Doğru çeviriler tek bir kelime çevrilmeden önce başlar. Çevirmenler sadece bir anahtar ve İngilizce bir ifade görürse tahmin ederler. Bu, doğru kelimelerin yanlış yerde kullanılmasına ve uygulamanın garip veya kaba hissetmesine yol açar.

Basit bir “bağlam paketi” çoğu tahmini ortadan kaldırır. Her dizgi için nerede göründüğünü (ekran ve bileşen), kullanıcının ne yapmak istediğini ve tonu (samimi, resmi, acil) ekleyin. Ayrıca bunun buton etiketi mi, hata mesajı mı, menü öğesi mi yoksa yardımcı metin mi olduğunu belirtin; bu kategoriler farklı şekilde çevrilir.

Alan kısıtlıysa bunu baştan belirtin. Web ve native ekranlar farklı şekillerde kırılır, bu yüzden önemli olduğunda sınırları tanımlayın: kısa buton etiketleri, sekme başlıkları, toast mesajları ve sabit kart içindeki her şey. Bir dizginin tek satırda kalması gerekiyorsa bunu belirtin. Satır sonları izinliyse, nerede güvenli olduğunu söyleyin.

"Çevirme" bölümünde bırakılması gereken parçaları açıkça işaretleyin. Ürün adları, plan isimleri, kupon kodları, API alanları ve {name} gibi yer tutucular değişmeden kalmalıdır. Yönerge olmazsa, çevirmenler bunları yerelleştirebilir ve uygulamanız anlamını yitirir.

Her dizgi için pratik paket:

• Ekran görüntüsü veya ekran adı (örneğin: "Checkout - Ödeme yöntemi")
• Tür ve niyet (ödeme onaylayan bir buton)
• Ton notu (sakin, güven verici)
• Kısıtlar (maks 18 karakter, tek satır)
• Korunan tokenlar (ürün adları, entegrasyonlar, {amount})

Yasal metin ve destek içeriğini ayrı akışlar olarak ele alın. Yasal metin genellikle onay gerektirir ve daha yavaş güncellenir; bu yüzden ürün UI dizgilerinden ayırın ve sürümleme yapın. Destek makaleleri ve yardım parçaları genellikle daha uzun çeviri gerektirir ve farklı bir sistemde tutulabilir.

Örnek: mobildeki bir “Continue” butonu webden daha sıkı bir sınıra ihtiyaç duyabilir. Çevirmenler bunu bilirse, genişleyen dillerde daha kısa bir fiil seçebilirler ve son dakika UI yeniden tasarımını zorlamaz.

Kırık UI'ı önleyen QA ve inceleme döngüsü

Yerelleştirmeden kaynaklanan UI bozulmaları nadiren ilk başta "hata" gibi görünür. Eksik bir etiket, iki satıra kayan bir buton veya yanlış değer gösteren bir yer tutucu olarak ortaya çıkarlar. İyi bir iş akışı, kullanıcılar görmeden önce bu sorunları ortaya çıkaran QA adımlarını içerir.

Geliştirme derlemelerinde pseudo-localization ile başlayın. Gerçek dizgileri daha uzun, aksanlı versiyonlarla değiştirin (ör. "[!!! Šéttïñĝš !!!]") ve uzunluğu %30–50 artırın. Bu, hem web hem native ekranlarda kırpmayı, örtüşmeyi ve sabit kodlanmış dizgileri hızlıca ortaya çıkarır.

Her build üzerinde otomatik kontroller ekleyin. İnsanların yüzlerce satırı incelerken kaçırdığı sıkıcı hataları yakalarlar:

• Herhangi bir yerelde eksik anahtarlar (fallback'ler sorunları gizler)
• Kullanılmayan anahtarlar (örn. ölü metin gönderimi)
• Yer tutucu uyuşmazlıkları ("Hello, {name}" vs "Hello, {username}")
• Bir yerel için geçersiz çoğul formları (zero, one, few, many)
• Mobil dizgilerde ham HTML gibi yasaklı kalıplar

Sonra net bir manuel onay döngüsü kullanın. Ürün anahtar ekranlar için anlam ve tonu doğrular, QA düzen ve etkileşimi kontrol eder.

Test matrisinizi küçük ama katı tutun. Her şeyi test etmeyin. Önce kırılma eğiliminde olanları test edin: giriş/kayıt, şifre sıfırlama, ödeme ve onay, ayarlar ve profil düzenleme, bildirimler ve boş durumlar ve tablolar, rozetler veya küçük butonlar içeren ekranlar.

Sorun raporlanırken düzeltmeyi kolaylaştırmak için belirgin olun. Yerel ayarı, cihaz ve OS sürümünü (veya tarayıcı ve genişlik), beklenen metni, gerçek metni ve kırpılmış alanı gösteren ekran görüntüsünü ekleyin. Çoğullaşma veya yer tutucularla ilgiliyse, tam anahtarı ve render edilmiş dizgiyi yapıştırın.

Yaygın hatalar ve nasıl önlenirler

Çoğu yerelleştirme hatası “çeviri problemi” değildir. İş akışı sorunlarıdır ve kırık UI, eksik metin veya kafa karıştırıcı mesajlar olarak görünürler.

Yaygın bir tuzak, sadece metni değiştirmek için anahtarları yeniden adlandırmaktır. Anahtarlar stabil ID olmalıdır, metin değil. checkout.button.pay'i checkout.button.pay_now yaparsanız, tüm eski çeviriler "eksik" olur ve geçmiş kaybolur. Anahtarı tutun, temel dildeki metni güncelleyin ve anlam değiştiyse bağlam ekleyin.

Bir başka sık hata, bir platformda metinleri sert kodlamaktır. Web ekibi anahtarları kullanırken mobil ekip hızlı bir düzeltme için literal metin koyabilir. Bir ay sonra iOS'ta İngilizce uyarılar gösterilir. "Kullanıcıya gösterilen metinlerde sert kodlama yok" kuralını web ve native için ortak yapın.

Yer tutucular, kelime sırasını varsaymak gibi ince hatalara yol açar. İngilizce "{count} items" ile çalışırken diğer diller farklı sıraya veya ekstra kelimelere ihtiyaç duyabilir. İsmi verilen yer tutucular kullanın ve tüm platformlarda tutarlılığı sağlayın.

Erken yakalanması gereken hatalar:

• Anahtarları metin gibi kullanmak ve mevcut çevirileri kırmak. Anahtarları stabil tutun.
• Bir anlam için bir anahtar kullanıp farklı anlamlarda yeniden kullanmak. Niyet farklıysa ayırın.
• Yer tutucu stillerini karıştırmak (bazı yerlerde isimlendirilmiş, bazılarında numaralandırılmış). Bir standarda karar verin.
• Sadece İngilizce test etmek. En az bir uzun metin dili ve bir sıkışık dilde hızlı kontrol yapın.
• Yayınlamadan önce bir geri dönüş planı olmadan göndermek. Eksik anahtar olduğunda ne olacağına karar verin.

Tek bir “uzun dil” ile test yapmak yeterli değildir. Almanca genellikle genişler, Çince ise boşluk sorunlarını gizleyebilir. Hızlı bir kontrol her ikisinde de yapın ve 0, 1, 2 gibi çoğul kenar durumlarını test edin.

Yayın öncesi fallback davranışında anlaşın. Örneğin: Fransızca eksikse İngilizceye dön, eksik anahtarları kaydet ve yalnızca kritik ekranlarda boşluk varsa yayını durdurun.

Hızlı kontrol listesi ve pratik sonraki adımlar

Yerelleştirme iş akışı küçük ve tekrarlanabilir kontrollerle sağlıklı kalır. Hedef basit: daha az sürpriz dizgi, daha az kırık düzen, daha az son dakika çeviri telaşı.

Bir UI değişikliğini birleştirmeden önce hızlıca şu "ops" sorunlarına bakın:

• Yeni anahtarlar adlandırma kurallarınıza uygun ve doğru namespace'te mi (ekran veya özellik)?
• Yer tutucular tüm dillerde tam olarak eşleşiyor mu (aynı değişkenler, aynı anlam)?
• Çoğul formları desteklediğiniz diller için eksiksiz mi (sadece İngilizce tekil/çoğul değil)?
• UI'da sert kodlanmış metin kalmadı mı (hata durumları ve boş durumlar dahil)?
• Yeni veya değişen metin için temel bağlam yakalandı mı (ekran görüntüsü veya net bir not)?

Yayınlamadan önce, yerelleştirmenin ilk bozulduğu yerleri odağa alacak kısa bir yayın QA'sı yapın. Zaman kutulu ama tutarlı olsun: her platform için en önemli kullanıcı akışları, bir RTL kontrolü, uzun metin ekranları (ayarlar, yasal, onboarding, tablolar, dar butonlar) ve birkaç yerelde tarih/sayı/para biçimlendirmesini kontrol edin.

Ekibinize uyan bir ritim belirleyin. Birçok ekip çevirileri haftalık günceller, sonra sürümden 1–2 gün önce dizgileri dondurur. Amaç son dakika kopya düzenlemelerini final QA ile karıştırmamaktır.

Hızlı kazanç sağlayan sonraki adımlar: konvansiyonlarınızı yazılı hale getirin (anahtar adlandırma, yer tutucular, çoğul kuralları, sahiplik), sonra bir pilot ekranı uçtan uca çalıştırın ve kırılan yerleri baz alarak ayarlayın.

Backend, web UI ve native mobil üzerinde tek bir platformda (ör. AppMaster) çalışıyorsanız, aynı ekranlar ve mantık tek bir konvansiyon paylaşabildiği için anahtarlar ve yer tutucuların tutarlı kalması daha kolay olur. Bu konvansiyonun stabil kalması, yerelleştirmenin kırılgan değil rutin hissetmesini sağlar.