10 yaygın i18n hatası ve bunlardan nasıl kaçınılır
Uluslararası i18n hatalarını öğrenin ve bunlardan nasıl kaçınacağınıza bakın. iOS, Android veya Web uygulamanızda yerelleştirme kalitesini bu en iyi uygulamalarla artırın.
i18n basit görünebilir — ta ki Alman kullanıcılarınızın kesik düğmeleri gördüğünü, Japon kullanıcılarınızın bozulmuş cümlecikler aldığını ve Arapça konuşan kullanıcılarınızın tamamen bozulmuş tasarımlarla karşılaştığını keşfedene kadar. Bunlar tesadüfi olaylar değildir. Bunlar, yerelleştirmeye ilk kez yaklaşan birçok geliştirme ekibinin yaptığı yaygın hataların öngörülebilir sonuçlarıdır. Bu kılavuzda en sık karşılaşılan 10 i18n hatasını inceleyeceğiz, neden olduklarını ayrıntılı olarak açıklayacağız ve her birini adım adım nasıl düzelteceğinizi göstereceğiz. Yeni bir uygulama mı kuruyorsunuz yoksa mevcut projeyi mi yükseltiyorsunuz — bu tuzaklardan kaçınmak size haftalarca debugging tasarrufu sağlar.
Hata #1: Sabitlenmiş dizeler
i18n hatalarının en temel olanı, dizelerin elle yazılmasıdır (hardcoding). Bu, geliştiricilerin önce özelliklerin çalışmasını sağlamaya odaklandığı ve sonra 'sonra temizleriz' diye plan yaptığı için olur. Ancak sonra hiç gelmez ve birden yüzlerce dosyada binlerce dize dağılır.
['İlk UI satırını yazmadan önce i18n çerçevesini kurun', 'Templates ve bileşenlerde hardcoded dizeleri tespit etmek için bir Linter eklentisi kullanın', 'Çeviri anahtarlarını açıklayıcı tutun ve özellik veya sayfaya göre organize edin']
UI kodunun ilk satırını yazmadan önce i18n çerçevesini kurun.
Şablonlar ve bileşenlerde sabitlenen dizeleri tespit etmek için bir linter eklentisi kullanılın.
Çeviri anahtarlarını açıklayıcı tutun ve özellik veya sayfaya göre düzenleyin.
Tipik Bir Senaryo
Bir geliştirici, JSX içinde doğrudan bir düğme etiketine yazıyor: <button>Submit Order</button>.
Uygulama İngilizce olarak dağıtılır ve sorunsuz çalışır. Altı ay sonra şirket Almanya'ya genişler.
Çeviri ekibi, 2.000'den fazla hardcoded dizeyi keşfeder. Güncellemeler 3 hafta sürer ve 47 hata meydana getirir.
Neden Bu Bir Problemdir
Gelişmiş bir kod tabanında hardcoded dizeler binlerceye ulaşabilir. Bunları sonradan çıkarmak her dosyayı değiştirmek, her bileşeni yeniden test etmek ve her yerde regresyon riski oluşturmak demektir.
Hardcoded dizeler, kaynak kodu, şablonlar veya bileşenlere doğrudan gömülüdür. Kod kendisini değiştirmeden çalıştırma zamanında çıkarılamaz, çevrilemez veya değiştirilmez.
İngilizce olmayan yerelleştirme kullanıcıları, çevirisiyle karışık çevrilememiş UI öğelerini görecekler — bu da karışık ve profesyonellikten uzak bir izlenim yaratır.
Bunu Nasıl Giderilir
Kullanıcılar tarafından görülen tüm dizeleri önceki kaynak dosyalarına taşıyın.
İlk bileşenini yazmadan önce çeviri çerçevesini (ör. next-intl, react-i18next, vue-i18n) kurduğunuzdan emin olun.
Kaynak dosya yapısı oluşturun (ör. messages/de.json) ve tüm dizeleri t('checkout.submitButton') gibi çeviri anahtarlarıyla referans gösterin.
UI bileşenlerindeki ham dize literal'larını işaret eden bir Linting kuralı veya Pre-Commit Hook ekleyin.
Hata #10: Her şeyi kelimesi kelimesine çevirmek
Tüm içerikler çevrilmemelidir. Marka adları, tüzel kişi adları, teknik terimler ve bazı ürün adları kendi dillerinde kalmalıdır. Aşırı çeviri yasal sorunlara, markalaşma tutarsızlığına ve kullanıcı karışıklığına neden olabilir.
["Çevirilmeyecek bir sözlük oluşturun ve tüm çevirmenlerle paylaşın", 'Marka ve yasal terimler için kilitli bölümler veya ayrı ad alanları kullanın', 'Çok anlamlı dizgiler için her zaman bağlam notları sağlayın, yanlış çevirileri önlemek için']
'Çevirme' olmayan kelimeler sözlüğü tutun ve tüm çevirmenlerle paylaşın.
Marka ve yasal terimler için kilitli segmentler veya ayrı ad alanları kullanın.
Yanlıç çevirileri önlemek için çok anlamlı olan dizgiler için her zaman bağlam notları sağlayın.
Tipik bir senaryo
Bir çeviri dosyası, şirket adı 'CloudForge Inc.' ve teknik terim 'OAuth 2.0 Token' gibi normal olarak çevrilebilir dize içerir.
İspanyol çevirmen 'CloudForge'yi 'ForjaNube' olarak ve 'OAuth 2.0 Token'ı da 'ficha OAuth 2.0' olarak çeviriyor.
Sonuç: Kullanıcılar şirketi gerçek adıyla bulamazlar ve İspanyolca belgeleri okuyan geliştiriciler, bilinmeyen çevrilmiş teknik terimler yüzünden şaşırır.
Neden bu bir sorun
Bir sözleşmede hatalı çevrilmiş bir marka adı tek başına sözleşmeyi geçersiz kılabilir. Aşırı çeviri hatalarını düzeltmek için her dildeki her dizede kontrol gerekir — haftalar sürebilir.
Eğer tüm dizeler bağlam olmadan çevrilmek üzere gönderilirse çevirmenler muhtemelen marka adlarını ('Apple' → 'Apfel'), yasal terimleri ('GmbH' → 'LLC') veya İngilizcede kalması gereken teknik terimleri çevirebilir.
Kullanıcılar tanıdıkları marka adı altında ürünleri bulamazlar, hukuki belgeler yanlış şirketi referans eder ve 'API Endpoint' gibi teknik terimler çevrildiğinde teknik belgeler okunaksız hale gelir.
Bunu nasıl düzeltersin
Çevrilmeyen içerikleri net bir şekilde işaretleyin ve çevirmenler için bağlam notları sağlayın.
Çevrilmeyen içerikleri listeleyen 'Çevrilmeyecek' bir sözlük oluşturun, marka adları, ürün adları, tüzel kişiler ve değiştirilmemesi gereken teknik terimler.
Çevrilmeyen içerikler için ayrı bir ad alanı (namespace) veya özel anahtarlar kullanın. Birçok i18n aracı kilitli bölümleri destekler, bu bölümleri çevirmenler düzenleyemez.
Çevirmen dosyalarına bağlamı açıklayan notlar/e-yorumlar ekleyin: 'Bu bir marka adı — çevrilmesin' ya da 'Terim — İngilizce olarak bırak'.
Hata #2: Dize zinciri
Fragmentlerden kelimeleri birleştirmek İngilizce'de mantıklı görünebilir, ancak diğer dillere geçtiğinde çalışmaz. Kelime dizimi, gramer ve cümle yapısı diller arasında dramatik şekilde değişir ve birleşik dizeler çevrilemez hale gelir.
['Çevirilen parçaları birleştirerek cümleler oluşturmayın', 'Daha netlik için konum belirten yer tutucular ('{name}') kullanın, pozisyonel ({0}) yerine', 'Her yer tutucunun içeriğini açıklayan bağlam yorumları sağlayın']
Çevirilen parçaları birbirine ekleyerek cümleler kurmayın.
Daha netlik için konum belirten yer tutucular ('{name}') kullanın, pozisyonel ({0}) yerine
Çevirmenler için her bir yer tutucunun ne içerdiğini açıklayan bağlam notları sağlayın.
Tipik bir senaryo
Geliştirici şöyle yazıyor: 'You have ' + count + ' items in your ' + cartType + ' cart' — İngilizce'de mükemmel çalışır.
Alman çevirmeni üç ayrı parça alır ve kelime dizilimini değiştirmesi gerektiği için dilbilgisel olarak doğru bir cümle kuramaz.
Sonuç: Alman kullanıcılar 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' görüyorlar — akıcı değil ve profesyonel değil.
Neden Bu Bir Problemdir
Birleştirilmiş her dize bir zaman bombasıdır. 20 dil ve 50 birleştirilmiş dize ile 1.000 potansiyel dilbilgisi hatası vardır ve bunlar manuel olarak düzeltilmelidir.
'Hoşgeldin ' + kullanıcıAdı + ', şu kadar ' + count + ' yeni mesajın var' gibi stringleri birleştirmek belirli bir sözdizimini gerektirir. Çevirmenler bağlamı olmayan parçalar alır ve bunları yeniden sıralayamazlar.
Kullanıcılar dilbilgisi açısından hatalı cümleler görüyor. Almanca'da fiil genelde cümlenin sonunda. Arapçada tüm yapı tersten. Sonuç, saçma gibi okunur.
Bunu Nasıl Düzelteceksin
ICU MessageFormat kullanın; bu sayede CLDR çoğul kuralları kutunun dışına çıkmadan desteklenir.
Birden fazla mesaj anahtarı yerine yer tutucularla tek bir mesaj anahtarı kullanın: 'cart.summary': ''{cartType}'' sepetinizde {count} ürün var.'
Çevirmenler dillerine özgü gerekli tüm çoğulları sağlarlar. Lehçe: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.
Çevirmenler şimdi serbestçe düzenleyebilir: ''{cartType}'' sepetinizde {count} ürün var — doğru Almanca.
Hata #3: Çoğul kullanımını yok sayma
İngilizce'nin iki çoğul formu vardır: tekil ve çoğul. Geliştiriciler genelde tüm dillerin aynı şekilde çalıştığını varsayarlar. Öyle değil. Lehçe 4 form, Arapça 6 form ve hatta Fransızca gibi diller bile İngilizce'den farklı olarak sıfırı ele alır.
['Her zaman ICU MessageFormat veya sayılabilir içerikler için eşdeğer bir kütüphane kullanın', 'Kendi çoğul mantığınızı asla yazmayın — CLDR kurallarına güvenin', '0, 1, 2, 5, 21 ve 100 gibi değerlerle çoğulları test edin, tüm kategorileri kapsayın']
Daima ICU MessageFormat veya eşdeğer bir kütüphane kullanın.
Kendi çoğul mantığınızı asla yazmayın — CLDR kurallarına güvenin.
Tüm kategorileri kapsamak için 0, 1, 2, 5, 21 ve 100 gibi değerlerle çoğulları test edin.
Tipik bir senaryo
Geliştirici yazar: count + (count === 1 ? ' Datei' : ' Dateien') — Almança dilinde doğru
Lehçe çevirmeni 4 form gerekir: 1 plik, 2-4 pliki, 5-21 plików, 22-24 pliki. Basit terner bunu ifade edemez.
Sonuç: Lehçe kullanıcılar '5 pliki' (yanlış form) görüyor, '5 plików' (doğru form) yerine ve uygulama bozulmuş görünüyor.
Neden Bu Bir Sorun
Uygulamanızdaki sayılabilir her isim için çoğul kuralları gerekir. Böyle 50 dize ve 20 dilde 1.000 çoğul kuralı manuel olarak yönetilemez.
Basit if/else kontrolleri (count === 1 ? 'Datei' : 'Dateien') yalnızca Almanca/İngilizce için geçerlidir. CLDR altı çoğul kategorisi tanımlar: zero, one, two, few, many ve other. Her dil başka bir alt kümeyi kullanır.
Kullanıcılar yanlış çoğul ekleri görebilirler; örneğin '1 haber' gibi. Resmi bağlamlarda bu güvenilirliği zedeler.
Bunu Nasıl Düzeltirsin
ICU MessageFormat kullanın; bu, CLDR çoğul kurallarını kutunun dışına çıkmadan destekler.
ICU Söz Dizimi ile mesajları tanımlayın: 'fileCount': '{count, plural, one {# Datei} other {# Dateien}}'.
Çevirmenler dillerine ilişkin tüm çoğulları sağlarlar. Lehçe: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.
Çalışma zamanında, etkin yerelin CLDR kurallarına göre doğru biçimi otomatik olarak seçen i18n kütüphaneniz vardır.
Hata #4: Sabit UI eleman genişlikleri
Tasarımcılar İngilizce olarak piksellik hassasiyetle düzenler oluşturur ve geliştiriciler bunları sabit genişliklerle uygular. Ancak çevrilmiş metin dramatik bir şekilde uzun veya kısa olabilir. Almanca metin İngilizce'ye göre yaklaşık %30 daha uzun, Çince ise yaklaşık %50 daha kısa olabilir.
['Çevirilebilir metin içeren öğeler için asla sabit piksel genişlik kullanmayın', 'Bir temel olarak %40 metin uzamasını planlayın — bazı diller daha da genişler', 'İçerik uzunluklarına uyacak düzenler için CSS Flexbox veya Grid kullanın']
Çevrilebilir metin içeren öğelerde sabit piksel genişlikleri asla kullanmayın.
Bir temel olarak metin genişlemesini %40 olarak belirleyin — bazı diller daha fazla genişliyor.
İçerik uzunluklarındaki değişkenliğe uyum sağlayan düzenler için CSS Flexbox veya Grid kullanın.
Tipik bir senaryo
Tasarımcılar 5 düğmeli bir gezinme çubuğu oluşturur, her biri tam olarak 100 px genişliğinde — İngilizce sürümde harika görünüyor.
Alman çevirisi: 'Settings' 'Einstellungen' olur (13 karakter karşı 8), 'Submit' ise 'Absenden' olur (8 karşı 6). Navigasyon çubuğu taşar.
Sonuç: Mobil cihazlarda düğmeler üst üste yığılır veya metin kesilir, bu da Almanca kullanıcılar için navigasyonu kullanılmaz hale getirir.
Neden bu bir sorun?
Sabit genişlikte her öğe potansiyel bir kırılma noktasıdır. Tipik bir uygulamada yüzlerce düğme, etiket ve kart bulunur ve hepsi metin uzamasını karşılamak zorundadır.
Sabit genişlikte kapsayıcı (width: 120px) ve sabit boyuttaki düğmeler kesilir veya metin genişlediğinde taşar. CSS overflow: hidden içerikleri sessizce gizlerken, overflow: visible düzeni bozar.
Kullanıcılar kesilmiş etiketler görüyorlar; örn. 'Einstellu...' yerine 'Einstellungen', veya düğmeler komşu öğeleri üzerine geçiriyor. Kritik işlemler okunamaz veya tıklanamıyor.
Bunu Nasıl Düzeltirsin
İçerik uzunluğuna göre tüm yerel ayarlara uyum sağlayan esnek düzenler tasarlayın ve uygulayın.
Sabit genişlikleri min-width, max-width ve esnek düzenlerle değiştirin. Alanı dinamik olarak dağıtmak için CSS Grid veya Flexbox kullanın.
Metin kapsayıcılarını kırılacak şekilde ayarlayın: overflow-wrap: break-word kullanın ve çevrilebilir içerik için white-space: nowrap uygulamayın.
UI'nizi tüm dizeleri %40 uzatan sahte yerelleştirme ile test edin — çevirmenlere göndermeden önce.
Hata #5: Tarih ve sayı biçimlendirme
Veri ve sayılar şaşırtıcı derecede evrensel görünebilir. Ancak 01/02/2025 ABD'de 2 Ocak ve Avrupa'da 1 Şubat anlamına gelir. Virgül ve nokta sayıların anlamını değiştirir: 1,000.50 (ABD) vs 1.000,50 (Almanya). Bu hatalı yapılırsa karışıklık, veri hataları ve güven kaybına yol açar.
['Verileri veya sayıları asla manuel olarak dize şablonlarıyla biçimlendirmeyin—her zaman Intl API\'lerini kullanın', 'Tüm verileri ISO 8601 formatında ve içerde para birimlerini en küçük birim (sent) olarak saklayın', 'Farklı ondalık işaretleri, tarih sıralamaları ve takvim sistemleri kullanan Localeler ile test edin']
Verileri veya sayıları asla string şablonları ile manuel olarak biçimlendirmeyin — her zaman Intl-APIs kullanın.
Tüm verileri ISO 8601 biçiminde ve para birimini en küçük birimde (cent) içsel olarak saklayın.
Farklı ondalık ayırıcıları, tarih sıralamaları ve takvim sistemleri kullanan yerellerle test edin.
Tipik bir senaryo
Geliştirici tarihi MM/DD/YYYY olarak ve fiyatı $1,234.50 olarak biçimlendirir — ABD kullanıcıları için doğru.
Bir Alman kullanıcı 03/04/2025 görür ve bunu 3 Nisan olarak yorumlar (DD/MM/YYYY kuralı). Fiyat $1,234.50 ise 1.234,50 gibi görünür.
Sonuç: Kullanıcı yanlış tarihte bir uçuş rezervasyonu yapıyor ve fiyat biçimini sorguluyor. Alman pazarında destek biletleri yüzde 15 artıyor.
Neden bu bir sorun?
Tarih ve sayı formatlaması uygulamanızdaki her veri görüntülenmesini etkiler: tablolar, diyagramlar, formlar, faturalar, raporlar. Küresel bir düzeltme yüzlerce örneği kapsar.
Sabit format dizeleri toLocaleDateString('en-US') veya şablon literalleri ile manuel biçimlendirme kullanıcıların gerçek yerelini görmezden gelir. Doğru yerel olsa bile yanlış takvim sistemi (Gregorian vs Hijri) sorunlara yol açar.
Kullanıcılar verileri yanlış okuyabilir ve verileri yanlış formatta girebilir. Avrupa'da bir kullanıcı 03/04/2025 gördüğünde bunu 3 Nisan olarak yorumlayabilir — bu, geç kalmış randevulara veya hatalı rezervasyonlara yol açar.
Bunu Nasıl Düzeltirsin
Veri, saat, sayı ve para birimleri için yerel ayarlı biçimlendirme yapan dahili Intl API'sini veya yerelleştirilmiş biçimlendirme kütüphanesini kullan.
Manuel biçimlendirmeyi, veriler için Intl.DateTimeFormat(locale) ve fiyatlar için Intl.NumberFormat(locale, { style: 'currency', currency }) kullanarak değiştir.
Verileri içsel olarak ISO 8601 formatında (YYYY-MM-DD) saklayın ve göstermek için kullanıcı yerel ayarını kullanın.
En az 5 farklı Locale ile kritik tarih/sayı görüntülerini test edin: en-US, de-DE, ja-JP, ar-SA ve zh-CN, en önemli biçimlendirme varyasyonlarını kapsamak için.
Hata #6: RTL dillerini unuttun
Sağdan sola okunan diller (RTL) Arapça, İbranice ve Farsça gibi 500 milyondan fazla kullanıcı tarafından kullanılır. Yine de çoğu uygulama yalnızca Sol'dan Sağa (LTR) düzen için tasarlanmıştır. RTL desteği yalnızca metinleri tersine çevirmek değildir — tüm kullanıcı arayüzünün simetrik olması gerekir.
['İlk günden itibaren mantıksal CSS Özelliklerini kullanın (inline-start/end, block-start/end)', 'Sprint incelemelerinde HTML öğesinde RTL için dir=rtl ile uygulamanızı test edin', 'Navigation, simgeler, formlar ve ilerleme göstergeleri için RTL-test kontrol listesi oluşturun']
İlk günden itibaren yalnızca mantıklı CSS Özelliklerini kullanın (inline-start/end, block-start/end).
Her sprint incelemesinde HTML öğesinde RTL olarak uygulamayı test edin.
Navigasyon, simgeler, formlar ve ilerleme göstergeleri için bir RTL test kontrol listesi oluşturun.
Bir tipik senaryo
Geliştirici tüm uygulama boyunca margin-left: 16px ve text-align: left kullanıyor — standart LTR uygulaması.
Uygulama Suudi Arabistan'da başlıyor. Geri Oklar ileri gösteriyor, Yanlar yanlış tarafta görünüyor ve sayısal veriler hizalanmıyor.
Sonuç: Arap kullanıcılar uygulamadan 30 saniye sonra ayrılıyor. Ekip sorunu düzeltmek için 4 hafta acil CSS refaktörü gerektiriyor.
Neden bu bir sorun?
RTL desteği uygulamanızın her bileşeniyle ilgilidir. RTL'yi sonradan eklemek genellikle CSS kurallarının %30-50'sini yeniden yazmayı ve her simge ile düzeni kontrol etmeyi gerektirir.
CSS Özellikleri gibi margin-left, padding-right, text-align: left ve float: left yönü sabitler. Yön işaretleri (oklar, ilerleme göstergeleri) yanlış yöne işaret eder. Border-radius değerleri bile yansıtılmalıdır.
Arap kullanıcılar yanlış köşede gezinmeyi görüyor, ilerleme çubuğu geri gidiyor ve UI öğeleriyle metinler çarpışıyor. Uygulama yabancı ve kullanımı zor hissediyor.
Bunu Nasıl Düzeltirsin
Mantıklı CSS Özelliklerini kullanın ve başlangıçtan itibaren RTL düzenini test edin.
Tüm fiziksel CSS Özelliklerini mantıksal karşılıklarıyla değiştirin: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.
HTML kök öğesinde etkin yerel ayara dayanarak dir niteliğini ayarla. RTL için CSS pseudo-class :dir(rtl) kullan.
Tüm simgelerin yön anlamına uygun olup olmadığını kontrol edin. Yön belirten simgeleri yansıtılmış sürümlerle değiştirin veya RTL bağlamlarında CSS transform: scaleX(-1) kullanın.
Hata #7: Metin içeren görseller
Metin görüntülerine gömülmüş metinler — ister kahraman afişlerinde, düğmelerde, infografiklerde veya ekran görüntülerinde olsun — yerelleştirme kabusu. Her dil için metin içeren her görsel manuel olarak düzenlenmelidir, tasarım maliyetlerini artırır ve sürümlerin gecikmesine yol açar.
['Çevrilebilen metni asla raster görüntülerine (PNG, JPG) doğrudan yerleştirmeyin', 'Hero-Banner ve CTA’lar için arka plan görsellerinde CSS Metin Örtüşü kullanın', 'App Store listelemeleri ve pazarlama sayfaları için ekran görüntülerinin üretimini otomatikleştirin']
Çevrilebilir metni doğrudan raster görüntülerine (PNG, JPG) yerleştirmeyin.
Hero-banner ve CTA'lar için arka plan resimleri üzerinde CSS metin örtüleri kullanın.
App Store listeleri ve pazarlama sayfaları için ekran görüntülerinin oluşturulmasını otomatikleştirin.
Tipik bir senaryo
Bir tasarımcı, görselin doğrudan üzerine yerleştirilmiş 'Start Your Free Trial' metniyle bir promosyon afişi hazırlar.
Çeviri ekibi tüm UI metinlerini çevirir, ancak Alman sayfasındaki afiş hâlâ İngilizce metin gösterir.
Sonuç: Alman açılış sayfasında karışık bir İngilizce afiş var. 15 dil için yerelleştirilmiş afişler oluşturmak tasarım çalışması olarak 3 gün sürer ve lansmanı geciktirir.
Neden bu bir sorun?
Tipik bir pazarlama sayfasında metin içeren 5-10 görsel vardır. 15 dil için bu yaklaşık 75-150 görsel varyantı anlamına gelir; bunların oluşturulması, bakımı ve tasarım değişikliklerinde güncellenmesi gerekir.
Görüntülerde (PNG, JPG, metin içeren SVG) metin olduğu için çeviri araçları tarafından çıkarılamaz. Her yerelleştirilmiş sürüm için tasarımcının kaynak dosyayı elle düzenlemesi, dışa aktarması ve yüklemesi gerekir.
Kullanıcılar yabancı bir dilde metin içeren görseller görüyor veya daha kötüsü, çevrilmiş UI ile çevrilmemiş görsellerin karışımıyla karşılaşıyor. Bu tutarsız görünüyor ve marka güvenini zedeliyor.
Bunu Nasıl Düzeltebilirsin
Metinleri resimlerden ayırmak için CSS Overlay'ları kullanın, çevirilebilir metin öğelerine sahip SVG'ler kullanın ya da dinamik görsel üretimini kullanın.
CSS kullanarak, çevirilebilir metni arka plan görsellerinin üzerine yerleştirin: metin katmanını görüntü kapsayıcısının üzerinde absolute konumlandırın.
Infographics veya diyagramlar için çeviri anahtarlarını referans eden <text> öğelerine sahip SVG'ler kullanın; ham stringleri doğrudan eklemek yerine.
Mobil uygulama ekran görüntülerini pazarlama materyallerinde otomatik olarak almak için Fastlane (Mobile) veya Playwright (Web) gibi araçlarla her locale için ekran görüntüleri alın.
Hata #8: Eksik çeviriler ele alınmıyor
Çeviriler geliştirme sırasında her zaman eksiktir. Yeni özellikler, çevirmenlerin çevirebileceğinden daha hızlı anahtarlar ekler. Doğru bir fallback mekanizması olmadan eksik çeviriler çökmelere, boş UI öğelerine veya kullanıcılara gösterilen ham çeviri anahtarlarına yol açabilir.
['i18n yapılandırmanızda daima en az bir dilin fallback olarak bulunduğundan emin olun', 'Eksik çeviri anahtarlarını izleme sisteminizde kaydedin ve takip edin', 'Bir Locale canlıya alınmadan önce minimum çeviri kapsama oranını belirleyin']
i18n kurulumunda en az bir yedek dil belirleyin.
Çeviri anahtarları eksik olanları izleme sistemine kaydedin.
Bir dil canlıya çıkmadan önce en az bir çeviri kapsamı oranını belirleyin.
Tipik bir senaryo
Geliştirici, 15 yeni çeviri anahtarı içeren 'Premium Features' adlı yeni bir bölüm ekler. İngilizce sürümü derhal sunulur.
Fransızca çevirileri henüz tamamlanmadı. Fransızca sayfası ham anahtarlar gösteriyor: 'premium.feature1.title', 'premium.feature1.description'.
Sonuç: Fransız kullanıcılar geliştirici anahtar adlarıyla dolu bozuk bir sayfa görüyor. Destek ekibi birçok hata raporu alıyor.
Neden bu bir problem?
Uygulamanız büyüdükçe İngilizce dizeler ile diğer diller arasındaki boşluk büyür. 100 dil ve 2.000 dize içeren bir uygulama anlık olarak 10.000'den fazla eksik çeviriyle karşı karşıya kalabilir.
Fallback mantığı olmadan eksik çeviri anahtarları undefined, null veya ham anahtar dizesini döndürebilir (ör. 'checkout.confirmButton'). Şablon motorları hatalar fırlatabilir, sayfa çöker veya hiçbir şey render edilmez.
Kullanıcılar bozuk bir UI görüyor: boş düğmeler, eksik etiketler veya 'nav.settings.title' gibi muğlak stringler yerine gerçek metin. Bu kafa karıştırıcı ve profesyonel olmayan bir durum.
Bunu Nasıl Düzeltebilirsin
Güçlü bir fallback zinciri kurun ve tüm dil sürümlerinde çeviri kapsamasını izleyin.
i18n yapılandırmanızda bir fallback dil zinciri kurun: eksik Fransızca (fr) anahtarları otomatik olarak İngilizce (en) geri döner.
Eksik anahtarları işleyen Missing-Key-Handler ekleyin ve çevrilmemiş anahtarları izleme sisteminize (ör. Sentry, Datadog) kaydedin; kullanıcı deneyimini bozmayın.
Her dil için çeviri kapsama yüzdesini izleyen ve kapsama yüzde belirli bir eşiğin altına düşerse sürümleri engelleyen bir çeviri kapsama panosu oluşturun (ör. %95).
Hata #9: Karakter kodlama sorunları
Karakter kodlama sorunları, yerelleştirmenin sessiz katili. İngilizce ve Avrupa dillerinde her şey doğru görünse de Çince, Japonca, Korece, Arapça veya Emoji eklediğinizde çokbaytlı karakterler bozulur Mojibake. Bu hatalar genellikle tespiti zordur.
['Tüm yerde UTF-8 kodlamasını kullanın — Kaynak dosyalar, veritabanı, API yanıtları ve HTML Meta-Tags', 'MySQL’de utf8 yerine utf8mb4 kullanın, Emoji dahil Unicode’un tamamını desteklemek için', 'CJK, Arapça ve Emoji ile gerçek içeriklerle erken kodlama sorunlarını tespit edin']
Her yerde UTF-8 kodlamasını kullanın — kaynak dosyalar, veritabanı, API yanıtları ve HTML meta etiketleri
MySQL'de tam Unicode aralığını Emoji dahil desteklemek için utf8mb4 kullanın (utf8 değil).
Kodlama sorunlarını erken yakalamak için CJK, Arapça ve Emoji içeren gerçek içerik ile test edin.
Tipik bir senaryo
Geliştirici, latin1 Collation'a sahip bir MySQL veritabanı kurar (eski standart). Uygulama kaynak kodu UTF-8 kullanır.
Japon kullanıcılar gerçek adlarıyla kayıt olur. Veritabanı '田中太郎' değerlerini bozulmuş baytlar olarak saklar.
Sonuç: Kullanıcı profili bozulmuş metin gösteriyor. Daha da kötüsü: CJK adları için arama ve sıralama bozuluyor; bu binlerce kullanıcıyı etkiler.
Neden bu bir sorun
Kodlama sorunları tüm yığının etrafında yayılır. Veritabanı karşılaştırması yanlış ayarlanırsa milyonlarca kayıt bozulabilir — onarım maliyetli veri taşıması gerektirir.
Inkonsistente Kodlama üzerinden yığın boyunca — Kaynak dosyalarında UTF-8, veritabanında Latin-1 ve API yanıtlarında Windows-1252 — Çokbaytlı karakterleri bozar. Yanlış yapılandırılmış tek bir katman '日本語' yi '????' veya '日本èª' olarak dönüştürebilir.
Kullanıcılar bozulmuş metinler, soru işaretleri veya dillerinin olması gereken yerlerde boş kutular görürler. En kötü durumda, form girdileri veritabanında bozulabilir.
Bunu Nasıl Düzeltirsiniz
Uygulama yığını'nın her katmanında UTF-8 kodlamasını tutarlı şekilde zorla.
Kaynak dosyaların tümünü UTF-8 olarak ayarla (editorünü ve .editorconfig'i yapılandır). HTML'e <meta charset='UTF-8'> ekle ve API yanıtlarında 'Content-Type: application/json; charset=utf-8' kullanım.
Veritabanını utf8mb4 olarak yapılandır (yalnızca utf8 değil; MySQL'de 3 baytlık alt kümesi). Bağlantı karşılaştırmasını utf8mb4_unicode_ci olarak ayarla.
Hedef yazı sistemlerini kapsayan fontları seçin: Latin, Kiril, CJK, Arapça, Devanagari. Sistem Font Yığını veya Google Fonts ile dil alt kümelerinden yararlanarak hızlı yüklemeye olanak tanıyın.
i18n uygulamanı test edin.
Uzunluk Uzatma Testi
Tüm çevrilmiş dizgileri %30-40 oranında uzatın ki metin uzaması oluşan dilleri (Almanca, Fince, Yunanca gibi) simüle edebilesiniz. Bu, sabit genişlikte konteynerler, kesilmiş etiketler ve taşan düğmeleri çeviriye başlamadan önce kapsar. Birçok pseudo-localization aracı bu özelliği yerleşik olarak sağlar.
"Senden" → "Ṡééééñðéñ_éxpáñðéð" (40% uzun)
Pseudolokalizasyon
Yapay yerelleştirme, her karakteri aksanlı bir karşılığıyla değiştirir (ör. 'a' → 'á') ve dizileri [!! ve !!] gibi etiketlerle sarar. Böylece hangi dizelerin doğrudan kodlandığını ve hangi dizelerin çeviri sisteminden geldiğini hemen görürsünüz. Regresyonları otomatik olarak yakalamak için CI boru hattınızın bir parçası olarak yapay yerelleştirmeyi çalıştırın.
Her ekran metninin tümü, [!! !!] işaretleri arasına alınmıyorsa hardcoded olarak kabul edilir ve dışa aktarılmalıdır. Bu test, gözden kaçan metinlerin yaklaşık %95'ini altında bir dakikada yakalar.
"Mesajı Gönder" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"
RTL Düzeni Testi
Aynı anda Arapça veya İbranice çeviri yoksa RTL yerleşimini HTML köküne dir='rtl' ekleyerek test edebilirsiniz. Bu, yönlü CSS hatalarını hemen ortaya çıkarır: yanlış hizalanmış simgeler, yanlış tarafta kenar boşlukları, bozuk gezinme ve yanlış sıralanmış Flex öğeleri. Bunu her sprint incelemesinde standart bir kontrol haline getirin — geçiş sadece 10 saniye sürer ve Production'da haftalar sürebilecek sorunları yakalar.
i18n kontrol listesi
['Kullanıcıya görünür tüm dizeler kaynak dosyalarına taşındı', 'Cümleleri oluşturmak için dize birleştirme kullanılmıyor', 'ICU MessageFormat veya eşdeğeri ile çoğul kuralları uygulanmıştır', 'Tarih, saat ve sayı biçimlendirmesi yerel ayarlı API'ler kullanır', 'Arapça veya İbranice içeriklerle RTL düzeni test edildi', 'Metin içeren öğelerde sabit genişlik olmadan esnek kullanıcı arayüzü', 'Yedek dil yapılandırıldı ve eksik anahtarlar için test edildi', 'UTF-8 kodlaması tüm dosyalar ve veritabanları üzerinde tutarlı', 'Uygulama Mağazası ve Google Play Mağazası meta verileri her pazar için yerelleştirildi', 'Her dil için ekran görüntüleri ve pazarlama varlıkları güncellendi']