Lokalizasyon Testi: Çok Dilli Uygulamalar için QA Rehberi

Çok dilli bir uygulama yayına almak, dizeleri bir çeviri ajansına teslim edip dosyaları geri birleştirmekten çok daha fazlasını gerektirir. Lokalize edilmiş sürümlerde kullanıcılara ulaşan hatalar nadiren çeviri hataları olur — bunlar entegrasyon başarısızlıklarıdır: Almancada etiketini kesen bir düğme, sağdan sola düzende ters görüntülenen bir tarih, Rusçada bozulan İngilizceye özgü kodlanmış bir çoğul form, Almanya'da virgülün standart olduğu yerde nokta kullanan bir fiyat formatı. Bunlar mühendislik ve QA sorunlarıdır; çoğu ekibin yeterince yatırım yapmadığı yapılandırılmış bir test yaklaşımı gerektirirler.

Bu rehber, lokalize edilmiş sürümleri titizlikle doğrulaması gereken QA mühendisleri ve geliştiriciler için hazırlanmıştır. Lokalizasyon testi türlerini, en değerli otomatik tekniği (pseudo-localization), pratik bir hata avı kontrol listesini ve lokalizasyon testini CI pipeline'larına entegre etmeyi ele alır.

Özet / Ana Çıkarımlar

Lokalizasyon testi, çeviri incelemesinden farklıdır — lokalize edilmiş bir uygulamanın işlevsel ve görsel doğruluğunu doğrular, çevrilen metnin dilbilimsel doğruluğunu değil.
Pseudo-localization en yüksek değerli otomatik tekniktir: kaynak dilimizdeki dizeleri, gerçek çeviri gerektirmeden düzen ve kodlama hatalarını ortaya çıkaran görsel olarak belirgin karakterlere dönüştürür.
En yaygın lokalizasyon hataları, önemli ölçüde genişleyen dillerde metin kırpılması (Almanca ve Fince İngilizce metni %30-50 genişletir), bozuk RTL düzenleri ve farklı sözcük sırasına sahip dillerde dilbilgisel olarak geçersiz çıktı üreten hardcoded dize birleştirmesidir.
Otomatik ekran görüntüsü karşılaştırma araçları (Percy, Chromatic) ve tarayıcı otomasyon çerçeveleri (Playwright, Cypress), her lokali manuel olarak inceleyen bir insana gerek kalmadan CI pipeline'ınızda lokalizasyon kontrollerini uygulayabilir.
Lokalizasyon testi üç noktada gerçekleşmelidir: her derlemede CI'da pseudo-localization kullanarak, her çeviri içe aktarımından sonra ve her büyük sürümden önce özel bir geçiş olarak.

Lokalizasyon Testi Nedir?

Lokalizasyon testi, bir yazılım uygulamasının belirli bir yerel ayar, dil veya bölge için uyarlandığında doğru çalıştığını ve düzgün görüntülendiğini doğrulama sürecidir. Açıkça çeviri incelemesiyle aynı şey değildir.

Çeviri incelemesi şunu sorar: "Bu dize Fransızcaya doğru çevrilmiş mi?" Bu, akıcı bir konuşmacı veya profesyonel bir çevirmen tarafından yanıtlanan dilbilimsel bir sorudur.

Lokalizasyon testi şunu sorar: "Uygulamanın Fransızca lokalize edilmiş sürümü doğru çalışıyor mu?" Bu, QA mühendisleri ve otomatik test süitleri tarafından yanıtlanan mühendislik sorusudur.

Bir çeviri mükemmel derecede doğru olabilir ve yine de bozuk bir UI üretebilir. "Benutzereinstellungen", "User Settings"in doğru Almanca çevirisidir — ve aynı zamanda %40 daha uzundur; bu da 13 karakter için boyutlandırılmış bir düğmenin, düzen genişlemeye göre tasarlanmamışsa bunu "Benutzereinstellun..." şeklinde keseceği anlamına gelir. Çeviri ekibi yanlış bir şey yapmadı. Düzen mühendisi Almanca'nın bileşik sözcük yapısını hesaba katmadı. Lokalizasyon testi bunu kullanıcıya ulaşmadan yakalar.

Lokalizasyon testinin kapsamı şunları içerir:

Lokaller arasında düzen ve görsel oluşturma
İşlevsel doğruluk (tarih seçiciler, form doğrulaması, sıralama, arama)
Lokale özgü veri formatlaması (sayılar, para birimleri, tarihler, adresler)
Latin olmayan yazı dizileri için kodlama ve karakter oluşturma
Arapça ve İbranice için sağdan sola (RTL) düzen doğruluğu
Çoğullama kuralları ve dinamik dizelerin dilbilgisel doğruluğu
Lokale özgü iş mantığı (vergi formatları, telefon numarası doğrulaması, posta kodu formatları)

Lokalizasyon Testi Türleri

Dilbilimsel Test

Dilbilimsel test, lokalizasyon QA'sı ve çeviri incelemesinin kesişim noktasıdır. İki dilli bir test uzmanı veya anadili konuşan biri, teknik olarak çevrilmiş ancak bağlamsal olarak yanlış dizeler — kısalığın kritik olduğu UI dizeleri, çevrilen versiyonun belirsiz olduğu düğme etiketleri veya tonun hedef kültür için uygunsuz olduğu hata mesajları — açısından kontrol ederek hedef yerel ayar etkin halde uygulamada ilerler.

Örnek: Bir onay iletişim kutusu İngilizcede "Are you sure?" der. İspanyolca çeviri "¿Está seguro?" teknik olarak doğrudur ancak resmi bir kayıt kullanır. Latin Amerika kullanıcılarını hedefleyen gündelik bir tüketici uygulamasında, resmi olmayan "¿Estás seguro?" daha uygun olur. Bu, bir test süitinin yakalayacağı bir hata değildir — kültürel bilgiye sahip insan test uzmanı gerektirir.

Dilbilimsel test genellikle yayın öncesi doğrulama ve yüksek trafikli lokaller için ayrılır. Otomatik pipeline'lara ölçeklenmez, ancak İngilizce konuşan geliştiriciler için görünmez olan hata sınıfını yakalamak için vazgeçilmez olmaya devam eder.

Kozmetik ve UI Testi

Kozmetik test görsel doğruluğa odaklanır: yüklenen gerçek çevrilen içerikle UI doğru görünüyor mu? Bu şunları kapsar:

Çeviriler kaynaktan daha uzun olduğunda metin kırpılması veya taşması
Beklenmedik biçimde katlanan dizelerden kaynaklanan düzen bozulmaları
Gömülü metin içeren (çeviri için hiçbir zaman çıkarılmayan) ikon ve resim yer tutucuları
Latin olmayan yazı dizileri için font oluşturma (CJK karakterleri, Arapça, Devanagari)
Aynı ekranda LTR ve RTL içeriği karıştırırken hizalama sorunları

Kozmetik hatalar, lokalize edilmiş sürümlerde bulunan en yaygın kategoridir ve otomatik ekran görüntüsü karşılaştırmasına çok uygundur.

İşlevsel Test

İşlevsel test, yalnızca UI'nin oluşturulduğunu değil, lokale özgü davranışın doğru çalıştığını doğrular. Örnekler:

en-US için A/G/Y formatında ve en-GB için G/A/Y formatında görüntülenen bir tarih seçici — seçicide tarih seçmek doğru değeri üretiyor mu?
Format doğrulayıcıya sahip bir telefon numarası giriş alanı — yerel ayar de-DE olduğunda Alman numaralarını (+49...) doğru kabul edip ABD formatındaki numaraları reddediyor mu?
Bir sıralama özelliği — lokale için doğru harmanlama kurallarını kullanarak alfabetik sıralama yapıyor mu? İsveççe "ä"yi "z"den sonra sıralanan bir harf olarak ele alır; naif Unicode sıralaması yanlış sonuçlar üretir.
Bir arama işlevi — locale-aware karşılaştırma kullanarak büyük/küçük harfe duyarsız eşleşme yapıyor mu (Türkçe "I" ve "i" iyi bilinen bir edge case'dir)?

İşlevsel lokalizasyon hataları genellikle en ciddi olanlardır çünkü görsel değil, davranışsal başarısızlıklardır.

Lokale Özgü Test

Lokale özgü test, bir dil yerine belirli bir bölge için doğruluğu doğrular. en-US ve en-GB aynı dili paylaşır ancak tarih formatı, para birimi, yazım kuralları ve posta kodu formatı açısından farklılık gösterir. fr-FR ve fr-CA aynı dili paylaşır ancak terminoloji ve para birimi açısından farklılık gösterir. Lokale özgü testler, bir lokalde geçerli olan ancak bir diğerinde bozulan varsayımları yakalar.

Pseudo-Localization

Pseudo-localization, lokalizasyon testindeki en değerli otomatik tekniktir ve gereğinden az kullanılmaktadır. Gerçek çeviri gerektirmeden, çevrilen metnin özelliklerini simüle eden görsel olarak belirgin karakterlere varsayılan dilinizdeki dizeleri programatik olarak dönüştürerek çalışır. Uygulama daha sonra bu pseudo-lokalde çalıştırılır ve test edilir.

Pseudo-Localization Hangi Sorunları Bulur

İyi tasarlanmış bir pseudo-locale dönüşümü aynı anda dört şey yapar:

Dize uzunluğunu genişletir — daha uzun çeviriler üreten Almanca ve Fince gibi dilleri simüle etmek için
ASCII karakterleri vurgulu veya ASCII olmayan eşdeğerleriyle değiştirir — kodlama sorunlarını ve font oluşturma problemlerini ortaya çıkarmak için
Dizeleri görünür sınırlayıcılarla sarar — hiçbir zaman çeviri için çıkarılmamış dizeleri (UI'deki hardcoded dizeler) açığa çıkarmak için
Yalnızca geçerli Unicode karakterleri kullanır — gerçek Unicode oluşturma başarısızlıklarını maskelememek için

Pseudo-Locale Dizesi Nasıl Görünür

"Submit Form" kaynak dizesi verildiğinde, bir pseudo-localization dönüşümü şuna benzer bir şey üretir:

[Ṡüḃṃïẗ Ḟöŕṃ !!!]

Köşeli parantezler [ ve ], dizenin herhangi bir karakterinin düşürülüp düşürülmediğini, kesilip kesilmediğini veya kırpılıp kırpılmadığını hemen görünür kılar. Vurgulu karakterler (Ṡ, ü, ḃ, ṃ, ï, ẗ) font kapsamını ve kodlama pipeline'larını test eder. Sonundaki !!! genişlemeyi simüle etmek için dizeyi dolgular — 10 karakterlik bir İngilizce dize, Alman genişleme oranlarına yaklaşan 16 karakterlik bir pseudo-locale dizesi olur.

Daha fazla örnek:

Kaynak Dize	Pseudo-Localized
`Save Changes`	`[Ṡàṽé Çḥàñġéš !!!]`
`Delete account`	`[Ḋéłéẗé àċċöüñẗ !!!]`
`Welcome, {name}!`	`[Ẇéłċöṃé, {name}! !!!]`
`Cancel`	`[Çàñċéł !!]`
`Settings`	`[Ṡéẗẗïñġš !!]`

Son örnekte {name}'in değişmeden korunduğuna dikkat edin. İyi bir pseudo-localization uygulaması, çalışma zamanı değerleri yerine koyarken bozulmaması için enterpolasyon yer tutucularını, HTML etiketlerini ve format dizelerini tanımlayarak korur.

Pseudo-Localization Nasıl Uygulanır

JavaScript/TypeScript projelerinde, i18next kütüphanesi bir post-processor eklentisi aracılığıyla pseudo-localization'ı destekler. Dize arama katmanında dönüşümü uygulayan bir pseudo locale yapılandırırsınız:

import i18next from 'i18next';

// Basit pseudo-localization dönüşüm fonksiyonu
function pseudoLocalize(str: string): string {
  const charMap: Record<string, string> = {
    a: 'à', b: 'ḃ', c: 'ċ', d: 'ḋ', e: 'é', f: 'ḟ', g: 'ġ',
    h: 'ḣ', i: 'ï', j: 'ĵ', k: 'ķ', l: 'ł', m: 'ṃ', n: 'ñ',
    o: 'ö', p: 'ṗ', q: 'q', r: 'ŕ', s: 'š', t: 'ẗ', u: 'ü',
    v: 'ṽ', w: 'ẇ', x: 'x', y: 'ý', z: 'ż',
    A: 'À', B: 'Ḃ', C: 'Ç', D: 'Ḋ', E: 'Ė', F: 'Ḟ', G: 'Ġ',
    H: 'Ḣ', I: 'Ï', J: 'Ĵ', K: 'Ķ', L: 'Ĺ', M: 'Ṁ', N: 'Ñ',
    O: 'Ö', P: 'Ṗ', Q: 'Q', R: 'Ŕ', S: 'Ṡ', T: 'Ṫ', U: 'Ü',
    V: 'Ṽ', W: 'Ẇ', X: 'X', Y: 'Ý', Z: 'Ż',
  };

  // {name}, %s, {{count}} gibi yer tutucuları koru
  const placeholderPattern = /(\{[^}]+\}|%[sdfi]|\{\{[^}]+\}\})/g;
  const parts = str.split(placeholderPattern);

  const transformed = parts
    .map((part) => {
      if (placeholderPattern.test(part)) {
        return part; // yer tutucuları değiştirmeden koru
      }
      return part
        .split('')
        .map((char) => charMap[char] ?? char)
        .join('');
    })
    .join('');

  // Genişleme dolgusu ve sarma köşeli parantezleri ekle
  const padding = '!'.repeat(Math.max(2, Math.floor(str.length * 0.4)));
  return `[${transformed} ${padding}]`;
}

React uygulamaları için, test ortamınızda NEXT_PUBLIC_LOCALE=pseudo (veya eşdeğerini) ayarlayarak ve tüm çeviri anahtarlarını döndürmeden önce dönüşüm fonksiyonundan geçirerek pseudo-locale enjekte edebilirsiniz.

Android için, build.gradle içindeki pseudolocales bayrağı iki yerleşik pseudo-locale etkinleştirir: en-XA (vurgulu Latin) ve ar-XB (yansıtılmış RTL düzeni). Bunlar Android platformuna yerleşiktir:

android {
    buildTypes {
        debug {
            pseudoLocalesEnabled true
        }
    }
}

iOS için, Xcode şema düzenleyicisinde (Ürün > Şema > Şemayı Düzenle > Seçenekler > Uygulama Dili) Accented Pseudolanguage ve Bounded String Pseudolanguage seçenekleri aracılığıyla pseudo-localization sağlar.

Pseudo-Localization'ı Destekleyen Araçlar

Android SDK: Yerleşik en-XA ve ar-XB pseudo-locale'leri
Xcode: Şema ayarlarında yerleşik vurgulu ve sınırlı pseudolanguage seçenekleri
i18next (JavaScript): Plugin tabanlı post-processor desteği
GNU gettext: Özel locale yapılandırmasıyla msginit --no-translator
Better i18n ve benzeri platformlar: Bazı i18n yönetim platformları, dönüşüm kodu yazmadan kaynak dizelerinizin pseudo-localized versiyonunu indirmenize olanak tanıyan yerleşik bir özellik olarak pseudo-locale dışa aktarımı sunar

Pseudo-localization, her derlemeye karşı çalışan CI pipeline'ınızın bir parçası olmalıdır. Çeviri ücretlerinde hiçbir maliyeti yoktur ve herhangi bir gerçek locale çalışması başlamadan önce bir hata kategorisini — kırpma, kodlama, hardcoded dizeler — yakalar.

Lokalizasyon Test Kontrol Listesi

Bu kontrol listesini herhangi bir lokalize edilmiş sürümde QA geçişleri sırasında kullanın. Otomatikleştirilebilir olarak işaretlenen öğeler test süitleri tarafından yakalanabilir; geri kalanlar insan incelemesi veya lokale özgü test senaryoları gerektirir.

Metin Oluşturma

Uzun genişleme locallerinde (Almanca, Fince, Hollandaca) UI dizelerinde görünür metin kırpılması veya üç nokta yok
Bitişik öğelere veya kapsayıcı sınırların dışına metin taşması yok
Tüm dizeler çevrilmiş — hedef locale'de kaynak dil dizeleri görünmüyor (pseudo-localization köşeli parantezleri bu kontrolün otomatik versiyonudur)
Font hedef yazı dizisindeki tüm karakterleri destekliyor (CJK, Arapça, Devanagari, Ermenice'yi kontrol edin)
Kodlama başarısızlıklarını gösteren bozuk veya değiştirme karakterleri (kutu karakterleri, soru işaretleri) yok

Dize Birleştirme ve Kompozisyon

Parçalardan oluşturulan dinamik dizeler hedef dilde dilbilgisel olarak doğru çıktı üretir — Almanca ve Rusça dilbilgisel hal uyumu gerektirir; sözcük sırası Japonca ve Korece'de farklıdır
Çoğul formlar locale için doğrudur — Rusçanın dört çoğul kategorisi vardır; Arapçanın altı vardır; İngilizcenin ikisi vardır
Cinsiyet uyumu, isim cinsiyetinin sıfat ve fiil formlarını etkilediği dillerde doğrudur (Fransızca, İspanyolca, Almanca)
Yer tutucular ({name}, %s, {{count}}) doğru yerine konulan değeri oluşturur ve çeviri tarafından bozulmaz

Tarih, Saat ve Takvim Formatlaması

Tarihler locale-doğru format kullanıyor (en-GB için GG/AA/YYYY, en-US için AA/GG/YYYY, ISO bağlamları için YYYY-AA-GG)
Saat, locale için uygun şekilde 12 saatlik veya 24 saatlik format kullanıyor
Saat dilimi görünümü locale'e uygun
Takvim haftası başlangıç günü doğru (Avrupa'nın çoğunda Pazartesi, ABD'de Pazar)
Göreli zaman dizeleri ("2 saat önce", "yarın") doğru lokalize edilmiş

Sayı ve Para Birimi Formatlaması

Ondalık ayırıcı doğru (en-US'de nokta, de-DE'de ve fr-FR'de virgül)
Binlik ayırıcı doğru
Para birimi sembolü konumu doğru (en-US'de miktardan önce: $10.00; bazı Avrupa locallerinde miktardan sonra: 10,00 €)
Para birimi sembolü locale için doğru — tüm İngilizce lokaller için USD varsaymayın
Yüzde formatlaması doğru (çoğu locale'de %75, bazı Türkçe bağlamlarda %75)

Sağdan Sola (RTL) Düzen

Sayfa düzeni doğru şekilde yansıtılıyor — navigasyon, kenar çubukları ve sütunlar sağ tarafa geçiyor
RTL içeriği için metin hizalaması sağa hizalanmış
Düğme sırası tersine çevriliyor — birincil eylem düğmesi RTL düzenlerinde sola taşıyor
Yönsel anlamı olan ikonlar (oklar, köşeli parantezler, geri düğmeleri) doğru şekilde yansıtılıyor
Form alanı etiketleri ve girişler doğru hizalanıyor
Karma LTR/RTL içerik (İngilizce ürün adıyla Arapça sayfa) doğru çift yönlü metin işlemeyle oluşturuluyor

Unicode ve Kodlama

Hedef yazı dizisindeki tüm karakterler uçtan uca, tam pipeline üzerinden doğru oluşturuluyor: veritabanı, API, oluşturma katmanı
Çift kodlama artifaktları yok (HTML varlıkları veya kaçış dizileri olarak görünen karakterler)
Giriş alanları hedef yazı dizisindeki Unicode karakterleri kabul edip doğru şekilde saklıyor
Arama ve filtreleme Unicode dizeleriyle doğru çalışıyor

Yer Tutucu ve Değişken İşleme

Tüm yer tutucu değişkenler çevrilen dizelerde mevcut (eksik {name} veya fazladan {0} yok)
Yer tutucu değerleri doğru sırayla ekleniyor — sıra diller arasında değişebilir
HTML işaretlemesi içeren çevrilen dizeler doğru etiket yapısını koruyor

Lokale Özgü İşlevsel Davranış

Sıralama düzeni locale-doğru (İsveç alfabetik sırası ASCII sıralamasından farklıdır)
Giriş doğrulaması locale-uygun formatları kabul ediyor (telefon numaraları, posta kodları, kimlik numaraları)
Adres formları alanları hedef ülke için doğru sırada ve doğru etiketlerle topluyor

Otomatik Test Yaklaşımları

Ekran Görüntüsü Karşılaştırma ve Görsel Regresyon

Görsel regresyon testi, uygulamanızın her locale'deki ekran görüntülerini yakalar ve bunları bir taban çizgisiyle karşılaştırır. Farklılıklar insan incelemesi için işaretlenir. Bu, ölçekte UI düzeyindeki lokalizasyon hatalarını yakalamak için en etkili otomatik yaklaşımdır.

Percy (BrowserStack tarafından) çoğu tarayıcı otomasyon çerçevesi ve CI sistemiyle entegre olur. Tam sayfa ekran görüntüleri veya bileşen düzeyinde anlık görüntüler yakalamak için yapılandırırsınız. Lokalizasyon testi için iş akışı şöyledir:

Test süitinizi en-US taban çizgisine karşı çalıştırın — taban çizgisi ekran görüntülerini onaylayın
Aynı süiti de-DE, ja-JP, ar-SA ve diğer aktif locale'lerle çalıştırın
Percy düzen farklılıklarını — taşma, kırpma, hizalama bozukluğu — görsel fark olarak işaretler
Temiz farkları onaylayın, işaretlenenleri araştırın

Chromatic (Storybook tarafından) aynı prensibi bileşen düzeyinde teste uygular. UI bileşenleri geliştirmek için Storybook kullanıyorsanız, Chromatic her hikayenin ekran görüntülerini locale'ler arasında yakalar. Bu, tam sayfa testlerinde ortaya çıkmadan önce bileşen düzeyindeki kırpma sorunlarını yakalamak için özellikle etkilidir.

Görsel regresyonun lokalizasyon için çalışmasını sağlamanın anahtarı tutarlılıktır: test verileri locale çalışmaları arasında aynı olmalıdır ve dinamik içerik (zaman damgaları, kullanıcı tarafından oluşturulan içerik) dondurulmalı veya mock'lanmalıdır, böylece meşru locale farklılıkları ekran görüntüsü değişiminin tek kaynağı olur.

Playwright ve Cypress ile Tarayıcı Otomasyonu

Playwright ve Cypress'in her ikisi de tarayıcı bağlam yapılandırması aracılığıyla locale değiştirmeyi destekler. Playwright'ta, tarayıcı bağlamı oluştururken locale'i ayarlarsınız:

import { test, expect } from '@playwright/test';

const locales = ['en-US', 'de-DE', 'fr-FR', 'ar-SA', 'ja-JP'];

for (const locale of locales) {
  test(`ödeme formu ${locale} dilinde doğru oluşturuluyor`, async ({ browser }) => {
    const context = await browser.newContext({
      locale,
      timezoneId: localeToTimezone[locale],
    });
    const page = await context.newPage();

    await page.goto('/checkout');

    // Metin taşması olmadığını doğrula
    const submitButton = page.locator('[data-testid="submit-button"]');
    const buttonBox = await submitButton.boundingBox();
    const buttonText = await submitButton.textContent();

    // Metnin kırpılmadığını doğrula (düğme metni görünür, üç nokta yok)
    await expect(submitButton).toBeVisible();
    await expect(submitButton).not.toHaveCSS('overflow', 'hidden');

    // Görsel karşılaştırma için ekran görüntüsü
    await expect(page).toHaveScreenshot(`checkout-${locale}.png`);
  });
}

Cypress'te, locale değiştirme genellikle Accept-Language başlığını ayarlayarak veya her testten önce uygulamanın locale durumunu manipüle ederek yapılır:

// cypress/support/commands.js
Cypress.Commands.add('setLocale', (locale) => {
  cy.intercept('**', (req) => {
    req.headers['Accept-Language'] = locale;
  });
});

// Bir testte
describe('Tarih formatlaması', () => {
  ['en-US', 'en-GB', 'de-DE'].forEach((locale) => {
    it(`${locale} için tarihleri doğru görüntüler`, () => {
      cy.setLocale(locale);
      cy.visit('/dashboard');
      cy.get('[data-testid="last-login-date"]')
        .invoke('text')
        .should('match', expectedDatePattern[locale]);
    });
  });
});

Hardcoded Dizeler için Linting

Statik analiz, hardcoded dizeleri test ortamına ulaşmadan önce yakalayabilir. eslint-plugin-i18next gibi ESLint eklentileri, çeviri dosyalarına çıkarılması gereken JSX ve JavaScript'teki dize literallerini işaretler:

# Eklentiyi yükle
npm install --save-dev eslint-plugin-i18next

# .eslintrc
{
  "plugins": ["i18next"],
  "rules": {
    "i18next/no-literal-string": "error"
  }
}

Android için, Android SDK'daki hardcoded-text lint kuralı, dize kaynağı referansıyla sarılmamış XML düzen dosyalarındaki dize literallerini işaretler. iOS için, SwiftLint kuralı nslocalizedstring_require_bundle ve üçüncü taraf linter'lar lokalize edilmemiş dize literallerini işaretleyebilir.

Bu lint kontrollerini CI'da çalıştırmak, QA sırasında değil kod incelemesi aşamasında yeni hardcoded dizelerin yakalanmasını sağlar.

Lokalizasyon Testinde Bulunan Yaygın Hatalar

Almanca Metin Taşması

Almanca, İngilizce eşdeğerlerinden önemli ölçüde daha uzun sözcükler üreten bileşik isimler oluşturur. "Checkbox", "Kontrollkästchen" (17 karakter) olur. "Settings", "Einstellungen" (13 karakter) olur. "Downloads" "Downloads" kalır — ancak "Upload failed", "Upload fehlgeschlagen" (13'e karşılık 20 karakter) olur. İngilizce metin için boyutlandırılmış sabit genişlikli düğmeler, sekme etiketleri ve gezinti öğeleri Almancada rutin olarak taşar.

Gerçek dünya örneği: İngilizce "Dashboard" görüntüleyen 120px sabit genişliğe sahip bir gezinti sekmesi, Almanca eşdeğeri olan "Instrumententafel"i kırpacak veya UI metin kaydırıyorsa sekmenin tek satırlık düzenini iki satıra bozacaktır.

RTL Düğme Sırası

Soldan sağa düzenlerde, iletişim kutuları geleneksel olarak birincil eylem düğmesini sağa ve ikincil eylemi (İptal) sola koyar: [ İptal ] [ Kaydet ]. Sağdan sola düzenlerde (Arapça, İbranice), bu sıra yansıtılmalıdır: [ Kaydet ] [ İptal ] — "Kaydet" solda (okuma yönünde görsel sağda). Metin hizalamasını döndüren ancak düğme sırasını tersine çevirmeyi unutan uygulamalar, birincil eylem düğmesinin RTL kullanıcıları için görsel olarak yanlış tarafta olduğu düzenler üretir.

Birleştirilmiş Dizeler Geçersiz Dilbilgisi Üretiyor

İngilizce geliştirilen uygulamalarda yaygın bir desen, cümleleri parçalardan oluşturmaktır:

// Kaynak kodu varsayımı
const message = `${count} ${itemLabel} selected`;
// Üretir: "3 items selected"

Rusçada, "item" sözcüğü sayıya ve dilbilgisel haline göre değişir: 1 "элемент" alır, 2-4 "элемента" alır, 5+ "элементов" alır. Arapçada altı çoğul kategorisi vardır. İngilizcenin iki çoğul sistemi için çalışan dize birleştirme, düzinelerce dilde dilbilgisel olarak geçersiz çıktı üretir. Düzeltme, ICU message format veya platformun çoğul API'sini kullanmaktır:

// ICU message format — doğru yaklaşım
t('items_selected', { count, defaultValue: '{count} items selected' });
// Çeviri dosyasında locale-özgü çoğul kuralları tanımlanmış

Yanlış Çoğul Form

Birleştirme hatasının daha ince bir versiyonu: uygulama ICU çoğul sistemini kullanır ancak çeviri dosyası dört form gerektiren Lehçe gibi bir dil için yalnızca iki form (one ve other) sağlar (one, few, many, other). Çeviri, dosya sözdizimsel olarak geçerli olduğu için incelemeden geçer, ancak işlenmeyen çoğul kategorisiyle eşleşen sayılar için "5 elementów", "5 element" olarak görüntülenir.

Saat Dilimi Görüntüleme Hatası

Zaman damgalarını sunucuda UTC kullanarak biçimlendiren ve ardından kullanıcının yerel saatini görüntülemek için tarayıcıya güvenen bir uygulama, test sırasında doğru çalışır — test uzmanı ve sunucu aynı saat dilimindeyken. Farklı saat dilimlerindeki kullanıcılar için üretimde başarısız olur ve teknik olarak bir saat dilimi işleme hatası olmasına rağmen bölgesel QA sırasında lokalizasyon hatası olarak ortaya çıkar.

Ne Zaman Test Edilmeli

Her Derlemede CI'da

Pseudo-localization kontrolleri, hardcoded dize linting ve pseudo-locale'e karşı otomatik ekran görüntüsü karşılaştırması her derlemede CI'da çalışmalıdır. Bu testler, sıfır çeviri maliyetiyle ve hızlı geri bildirim döngüleriyle geniş bir hata sınıfını — kırpma, kodlama, hardcoded dizeler — yakalar. Başarısız olan pseudo-locale ekran görüntüsü testi, değişikliği günler sonra derlemeyi inceleyen bir QA mühendisine değil, değişikliği yapan geliştiriciye görünür.

Her Çeviri İçe Aktarımından Sonra

Bir çeviri yönetim sisteminden yeni bir çeviri toplu işlemi içe aktarıldığında, etkilenen diller için tam locale-özgü test süitini çalıştırın. Bu, bir çevirmenin doğru çevrilmiş ancak alışılmadık derecede uzun bir dize ürettiği, yer tutucunun yanlışlıkla silindiği veya çevirinin bir kodlama açığını ortaya çıkaran özel karakterler içerdiği durumları yakalar. İçe aktarımdan sonraki otomatik test çalışması, manuel olarak zamanlanmış değil, içe aktarma pipeline'ı tarafından tetiklenmiş olarak otomatik gerçekleşmelidir.

Büyük Sürümlerden Önce

Her büyük veya bölgesel sürümden önce, yüksek öncelikli locale'ler için insan liderliğinde bir lokalizasyon testi geçişi yapın. Bu, anadili konuşanlar tarafından dilbilimsel test, locale'e özgü özelliklerin işlevsel testi ve önceki sürümden bu yana değişen herhangi bir UI akışının incelemesini içerir. Yüksek trafikli locale'ler (en büyük kullanıcı nüfusunuzu temsil eden diller) bu tam geçişi almalıdır; daha düşük trafikli locale'ler büyük sürümler arasında yalnızca otomatik kapsam alabilir.

SSS

Lokalizasyon testi ile i18n testi arasındaki fark nedir?

I18n testi, uygulamanın birden fazla locale'i destekleyecek şekilde oluşturulduğunu doğrular — locale API'lerini doğru kullandığını, tüm dizeleri dışsallaştırdığını, Unicode girişini işlediğini ve hardcoded locale varsayımlarından kaçındığını. Lokalizasyon (l10n) testi, belirli bir lokalize edilmiş sürümün belirli bir hedef locale için doğru çalıştığını doğrular. I18n testi bir kez gerçekleşir (temeli oluştururken); l10n testi gönderdiğiniz her locale için gerçekleşir.

Lokalizasyon testi için anadili konuşanlara ihtiyacım var mı?

Dilbilimsel test için — çeviri kalitesini, tonunu ve kültürel uygunluğunu doğrulamak için — evet. İşlevsel ve kozmetik lokalizasyon testi için anadili konuşanlar gerekli değildir. Almanca konuşmayan bir QA mühendisi yine de Almanca metnin bir düğmeyi taşırmadığını, tarihlerin doğru biçimde görüntülendiğini ve RTL düzeninin Arapça için doğru şekilde yansıtıldığını doğrulayabilir. Otomatikleştirilebilir kontroller dilbilimsel bilgi gerektirmez.

CI'da kaç locale test etmeliyim?

Pseudo-localization ve hardcoded dize linting'i locale sayısından bağımsız olarak her derlemede çalıştırın. Tam otomatik locale testleri için pratik bir yaklaşım, temsili bir küme test etmektir: bir sağdan sola locale (Arapça veya İbranice), bir uzun genişleme locale'i (Almanca), bir CJK locale'i (Japonca veya Çince) ve Latin olmayan yazı dizisi kullanan bir locale (destekliyorsanız). Bu, her locale'i her derlemede test etmeden dört büyük lokalizasyon başarısızlığı kategorisini kapsar.

Yayından önce eksik çevirileri yakalamak için en iyi yöntem nedir?

En güvenilir yaklaşım, kaynak dil dosyasında bulunan ancak tamamlandı olarak işaretlenmiş bir locale dosyasında olmayan bir çeviri anahtarı olduğunda derlemeyi başarısız kılmaktır. Çoğu i18n çerçevesi bunu yapılandırma yoluyla destekler (i18next'in missingKeyHandler'ı vardır; ICU tabanlı sistemler bütünlüğü komut satırı araçlarıyla doğrulayabilir). Her locale'e karşı görsel regresyon testleri de eksik çevirileri görünür farklılıklar olarak ortaya çıkarır — Almanca bir sürümde bir dize İngilizceye geri dönerse, ekran görüntüsü İngilizce metin gösterir ve fark işaretlenir.

Hangi locale'leri en kapsamlı şekilde test edeceğime nasıl öncelik veririm?

Kullanıcı etkisine göre önceliklendirin: en yüksek aktif kullanıcı nüfusuna sahip locale'ler, şirketinizin düzenleyici yükümlülükleri olan pazarlara yönelik locale'ler ve kaynak dilinizden yapısal olarak en farklı olan locale'ler (RTL, CJK ve karmaşık çoğul locale'ler neredeyse her zaman Latin yazı dizisi locale'lerinin üretmediği hatalar üretir). Bu öncelikli locale'ler içinde tam test yığınını uygulayın — otomatik, görsel regresyon ve insan incelemesi.

Sonuç

Lokalizasyon testi, çeviri tamamlandıktan sonra gerçekleşen bir adım değildir. Bir geliştirici ilk dışsallaştırılmış dizeyi yazdığında başlayan ve her sürümde devam eden bir mühendislik disiplinidir. En etkili programlar pseudo-localization'ı birinci sınıf bir CI kontrolü olarak ele alır, her çeviri içe aktarımından sonra otomatik locale testleri çalıştırır ve insan QA çabasını otomasyonun değerlendiremeyeceği dilbilimsel ve kültürel nüanslar için saklar.

Her lokalizasyon hatasındaki ortak iplik — Almanca taşması, bozuk RTL düzeni, dilbilgisel olarak geçersiz çoğul, yanlış tarih formatı — kaynak dilde yapılan ve bir locale tarafından açığa çıkarılana kadar sorgulanmayan bir varsayımdır. Pseudo-localization bu varsayımları herhangi bir çevirmen dahil olmadan otomatik olarak sorgular. Yapılandırılmış bir kontrol listesi bunları QA sırasında sistematik olarak sorgular. Otomatik ekran görüntüsü karşılaştırması bunları pipeline'ınızda sürekli olarak uygular.

Henüz kullanmıyorsanız pseudo-localization ile başlayın. Kontrol listesini yayın sürecinize ekleyin. Playwright veya Cypress locale testlerini CI'a entegre edin. Bu üç adım, lokalizasyon hatalarının büyük çoğunluğunu üretimde bulmanın maliyetinin çok küçük bir bölümünde yakalayacaktır.

Referanslar

Son güncelleme: Mart 2026

Lokalizasyon Testi: Çok Dilli Uygulamalar için QA Rehberi