Soru, başlangıçta Batı Latin alfabelerine göre tasarlanan, miras kalmış kurumsal uygulamaların küreselleşmesinden kaynaklanmıştır; burada metin yönlülüğüne, karakter kodlamasına ve sabit genişlikteki düzenlere dair varsayımlar, Orta Doğu veya Asya pazarlarına genişlerken sistematik hatalar yaratmaktadır. Erken uluslararasılaşma çabaları genellikle yerelleştirmeyi yalnızca çeviri olarak ele almış, oysa RTL (Sağdan-Sola) yazılar yansıtılan düzenler gerektirirken, Japonca gibi karmaşık yazılar dikey metin dikkate almayı gerektirmekte ve kültüre göre sıralama dizileri dramatik bir şekilde değişebilmektedir.
Manuel QA, görünmeyen kodlama katmanlarının doğrulanması (UTF-8 ile UTF-16), LTR ürün adlarının RTL arayüzlerine yerleştirildiğinde ince BiDi (İki Yönlü) algoritma hatalarının tespit edilmesi ve yerel bilgilere dayalı işlevlerin (tarih ayrıştırma, döviz yuvarlama, adres biçimlendirme) CLDR standartlarını ihlal etmeden saklı iş mantığını koruyup korumadığını doğrulama zorluğuyla karşı karşıyadır. Görselleştirilmiş regresyon otomasyon araçlarının yokluğu bunu daha da zorlu hale getirmekte, test edilmesi gereken DatePicker'ın "٢٠٢٤/٠٥/١٥" yerine "2024/05/15" göstermesinin yalnızca kozmetik bir hata olmadığını, yanlış İslam takvimi geri dönüş mantığını gösterdiğini anlamak için test edenlerin manuel olarak tanımalarını gerektirmektedir.
Çözüm, Sahte Yerelleştirme ile erken bir duman testi olarak kullanılan, ardından Unicode aralıkları için Sınır Değer Analizi (örn. Arapça 0600-06FF, CJK 4E00-9FFF) ve yerel dildeki konuşmacılarla birlikte Kültürel Kabul Testi yapan Yerel Matris Testi metodolojisini uygulamaktadır. Bu, BiDi kontrol karakterlerini (örneğin LRE, RLE, PDF) kullanarak test verileri oluşturmaya, sayı biçimlendirmeleri için ICU (Unicode için Uluslararası Bileşenler) kütüphanesi uygulamalarını doğrulamaya ve document.dir niteliklerini zorlamak için Tarayıcı Geliştirici Araçları kullanarak yansıma bütünlüğü için flexbox/ızgara düzenlerini manuel olarak incelemeye yol açmaktadır.
Miras Java Spring monolitinin B2B satın alma işlemlerini Suudi Arabistan ve Japonya'ya genişletmesi, başlangıçta İngilizce ve Fransızca (LTR) için tasarlanmış bir arayüze Arapça (RTL) ve Japonca (Han + Kana yazıları) getirmiştir. Uygulama, sunucu tarafında JSP ile istemci tarafında jQuery render kullanmaktaydı ve veritabanı katmanı varsayılan ASCII sıralama ayarlarına dayanmaktaydı. İş paydaşları, manuel test aşamasının üç hafta içinde tamamlanmasını talep etti ve bu, ek SaaS yerelleştirme test araçları satın almadan test metodolojisinde kısıtlamalar yarattı.
Kritik hata, satın alma siparişi onay ekranında ortaya çıktı: bir alıcı, hem Arapça rakamlar (١, ٢, ٣) hem de Latin karakterler (SKU kodları) içeren bir ürün adı girdiğinde, BiDi algoritması CSS flexbox düzeninin miktar ve fiyat alanlarını görsel olarak karıştırmasına neden oldu. Ayrıca, PostgreSQL veritabanı Japonca ürün adlarını ASCII byte değerlerine göre sıraladı, bu da kullanıcılara alfabetik olarak rastgele görünen arama sonuçları sağladı. Bu sorunlar, DOM'da HTML doğru bir şekilde render edildiği için otomatik birim testlerine görünmedi; yalnızca görsel denetimler, RTL yansımanın maliyet ve miktar alanları arasındaki matematiksel ilişkiyi ters çevirdiğini ortaya çıkardı.
İlk olarak, her yerel için ardışık test, Arapça'nın detaylı bir şekilde doğrulanmasını, ardından Japonca'ya geçişi içeriyordu; bu, derin bir kültürel odaklanma ve dil değiştirme yükü olmadan kusurları izole etme avantajı sağlıyordu. Ancak, bu yaklaşım, Arapça oturum çerezlerinin kullanıcılar dil değiştirirken Japonca UTF-8 kodlamasıyla etkileşime girmesi gibi yerel çapraz kontaminasyonu tespit edemedi ve test için gereken takvim süresini iki katına çıkardı. Yerel özel CSS dosyaları arasındaki entegrasyon hatalarını kaçırma riski, ardışık odaklanmanın faydalarından daha ağır basıyordu, özellikle de sıkı üç haftalık son tarih göz önüne alındığında.
İkincisi, otomatik Selenium görsel regresyonu, BrowserStack cihazları arasında ekran görüntüleri almayı ve LTR ile RTL düzenleri arasında piksel farklılıklarını karşılaştırmayı önermiştir. Bu, CSS kenar boşluğu kaymalarını tespit etmek için hız ve tutarlılık sunarken, miras JSP ön yüzü, yapıların arasında değişen dinamik olarak üretilen CSS sınıf adları ve mutlak konumlandırma kullandığından, piksel karşılaştırma araçlarının güvenilirliğini, büyük bir bakım yükü olmadan sağlamıyordu. Üstelik, Selenium yalnızca görsel görünümü doğrulayarak BiDi mantıksal sıralaması veya Unicode sıralama doğruluğunu doğrulayamıyordu, bu da işlevsel gereksinimler için yetersiz hale getiriyordu.
Üçüncüsü, yüksek riskli kombinasyonları seçerek bir Yerel İkili Test matrisinin tasarımı yapıldı: Arapça Windows/Chrome, Japonca macOS/Safari üzerinde ve BiDi stres testleriyle gömülü LRE, RLE ve PDF kontrol karakterleri içeren karışık içerik senaryoları. Bu yöntem, istatistiksel olarak en sorunlu ortam kombinasyonlarına öncelik verdi ve test edenlerin farklı LCID ayarları arasında tarih formatlama ve para birimi sembol yerleşimi için ICU kütüphane çıktılarını manuel olarak incelemelerine olanak tanıdı. Kaynak açısından test uzmanlarının gereksinimi yüksek olmasına rağmen, otomatik script bakımına ihtiyaç duymadan ön uç JavaScript ile arka uç Java kontrolörleri arasındaki UTF-8 kodlama el sıkışmasını kapsamlı bir şekilde sağlamaktaydı.
Ekip, kapsamlılık ile pragmatik kısıtlamalar arasında bir denge sağlayan üçüncü yaklaşımı seçti; özel olarak, LTR düşük yoğunluklu saatlerde test edilen RTL düzenleri için "ayna saatleri" oluşturma kararı alındı, bu da Geliştirici Araçları denetim süresini artırmayı maksimize etti. Test edenler, ürün açıklamalarına sınır koşullarını zorlamak için ZWSP (Sıfır Genişlikte Boşluk) karakterleri ve RLM (Sağdan-Sola İşareti) enjekte etti ve aynı anda Suudi ve Tokyo saat dilimlerini simüle etmek için Tarayıcı yerel ayarlarını kullandı. Bu karar, BiDi algoritması hatalarının ve Unicode normalizasyon hatalarının tespit edilmesine, saf UI piksel mükemmelliğinin ötesinde öncelik verilmesine yardımcı oldu, bu da satın alma siparişlerinde veri bozulma riskini azaltmaya yönelik iş riskine uyum sağladı.
Sonuç, on dört P1 hatasını belirledi; bunlar arasında, Unicode normalizasyon sürecinde karmaşık Japonca karakterlerin tek tırnak işaretlerine dönüşmesinin neden olduğu kritik bir SQL enjeksiyon açığı vardı. Dağıtımdan sonra, Suudi kullanıcılar, ilk ay operasyon sırasında sıfır düzen bozulması bildirdi ve Japonca müşteri arama doğruluğu, UCA-uyumlu sıralama dizilerinin uygulanmasından sonra %340 oranında iyileşti. Manuel test metodolojisi, satın alma siparişi hatalarından kaynaklanan gelir kaybını başarılı bir şekilde önlerken, gelecekteki Korece ve İbranice genişlemeleri için yeniden kullanılabilir bir i18n test veri kümesi oluşturmuştur.
Nasıl BiDi (İki Yönlü) algoritması hatalarını manuel olarak tespit edersiniz, LTR metin (URL'ler veya ürün SKU'ları gibi) RTL içerik içinde gömülü olduğunda, dili anlamadan?
Adaylar genellikle yalnızca görsel denetime dayanıyorlar ve BiDi'nin mantıksal ve görsel sıralamayı kontrol etmeyi gerektirdiğini gözden kaçırıyorlar. Doğru yaklaşım, şüpheli metni Bidi render kapalı olan bir düz metin editörüne (örn. Notepad++) kopyalamayı içerir; eğer "ABC123" veritabanında "123CBA" olarak görünüyorsa ama ekranda "ABC123" ise, BiDi algoritması yanlışlıkla LTR önceliği uygulamaktadır. Test edenler, Arapça harflerini, İbranice noktalama işaretlerini ve İngilizce rakamları (örn. "מוצר_ABC_123_تجربة") birleştiren "sahte yerelleştirilmiş" dizeleri oluşturarak, seçim vurgusunun (tıkladığınızda sürükleme) mantıksal sıralamayı takip ettiğini doğrulamalıdır. Ayrıca, HTML kaynaklarının dir="auto" ile açık dir="rtl" olup olmadığını kontrol etmek, tarayıcının yönü tahmin edip etmediğini ortaya çıkarır; bu, kullanıcı tarafından üretilen içerikte RTL işaretleri yoksa başarısız olur.
Arapça tipografisinde Şekil Oluşturma nedir ve neden manuel testte kozmetik sorunların ötesinde işlevsel hatalara neden olur?
Arapça Şekil Oluşturma (veya Glyph kompozisyonu), karakterlerin bir kelime içindeki konumlarına (ilk, orta, son, izole) bağlı olarak nasıl değiştiğini ifade eder. Adaylar, bunun işlevsel testi etkilediğini gözden kaçırırlar çünkü aynı Unicode kod noktaları, font ligatür desteğine göre farklı şekilde işleyebilir. Örneğin, Lam-Alef ligatürü (ﻻ) iki karakteri temsil eden tek bir glif; eğer bir arama işlevi ham Unicode (iki ayrı kod noktası) dizisini indeksliyorsa ancak kullanıcı girişi bu ligatürü (bir kod noktası) birleştiriyorsa, arama sıfır sonuç döner, görsel kimliğine rağmen. Doğru manuel test, metni UI'dan bir hex editörüne veya Python repr() çıktısına geri yapıştırarak kod noktası dizilerinin eşleşmesini doğrulamayı ve ligatürleri açıkça devre dışı bırakacak fontlar (örn. Courier New) ile test etmeyi gerektirir.
Okuyamadığınız diller için Sıralama (sıralama düzeni) doğruluğunu nasıl doğrularsınız, örneğin İsveççe'nin 'Å' harfini 'Z' harfinden sonra ayrı bir harf olarak kabul ettiğini doğrulamak gibi?
Test edenler, sıklıkla ASCII sıralama düzeninin veya veritabanı varsayılan sıralamasının yeterli olduğu varsayımında bulunurlar. Çözüm, Referans Veri Doğrulamadır: resmi hükümet veya akademik kelime listeleri (örn. İsveççe Språkrådet sözlükleri) edinmek ve bunları CSV test verileri olarak içe aktarmak, ardından uygulama çıktısını beklenen sıralama ile karşılaştırmak için diff araçları kullanmaktır. Büyük/Küçük Harf Duyarsız eşleşme için, Türkçe 'İ' (noktalı büyük I) ile küçük 'i' harflerinin doğru bir şekilde eşleşmesini sağlarken, İngilizce 'I' harfinin 'i' harfine eşleştiğini doğrulamak için Türkçe Yerel Ayarı (tr-TR) ayarlarıyla Tarayıcı tercihlerinde kontrol edilmelidir. Manuel test edenler ayrıca, dilsel uzmanlık mevcut olmadığında CLDR (Ortak Yerel Veri Deposu) tablolarına karşı doğrulama yaparak, Digraphs ile Sınır Testi yapmalıdır (örn. Ch İspanyolca'da, LL geleneksel Welsh'te) ve bunların ayrı harfler değil, tek bir birim olarak sıralandığından emin olmalıdır.