Çok Dilli Uygulamalar İçin Locale Emülatörleri ve Test Araç…

Çok Dilli Uygulamalar İçin Locale Emülatörleri ve Test Araçları

Kapsamlı bir lokalizasyon testi yapmadan çok dilli bir uygulama yayınlamak, mobil uyumluluğunu kontrol etmeden bir web sitesi açmaya benzer. Bir şeyler mutlaka bozulacaktır — metinler container'lardan taşacak, tarihler yanlış biçimde görüntülenecek ve sağdan sola (RTL) düzenler çöküp gidecektir. Bu rehber, söz konusu sorunları kullanıcılarınızdan önce tespit etmenize yardımcı olan temel locale emülatörlerini ve test araçlarını ele almaktadır.

Temel Çıkarımlar

Locale emülatörleri, sistem ayarlarınızı değiştirmeden farklı bölge ve dilleri simüle etmenizi sağlar; bu sayede düzinelerce locale'ı hızlıca test etmek pratik hâle gelir.
Pseudo-localization, gerçek çeviriler mevcut olmadan önce, geliştirme sürecinin erken aşamalarında düzen sorunlarını ve hardcoded string'leri tespit eder.
RTL testi, özel bir dikkat gerektirir — metni çevirmek yeterli değildir; Arapça, İbranice ve diğer RTL diller için düzenin tamamının yansıtılması şarttır.
CI/CD pipeline'ınızdaki otomatik lokalizasyon testleri, gerilemeleri önler ve eksik çevirileri production'a ulaşmadan yakalar.
Birden fazla test yaklaşımını birleştirmek — emülatörler, pseudo-localization, RTL kontrolleri ve otomatik testler — en kapsamlı kapsamayı sağlar.

Lokalizasyon Testi Neden Önemlidir?

Lokalize edilmiş uygulamaları nasıl test edersiniz? Öncelikle lokalizasyon testini QA sürecinizin birincil öncelikli bir konusu olarak ele alarak başlayın. Farklı bölgeleri simüle etmek için locale emülatörleri kullanın, düzen sorunlarını erken yakalamak için pseudo-localization uygulayın, RTL düzenlerini özel araçlarla test edin ve dağıtımdan önce eksik ya da bozuk çevirileri yakalamak amacıyla CI/CD pipeline'ınızda string doğrulamasını otomatikleştirin.

Lokalizasyon hataları son derece ince ve farkedilmesi güçtür. Genellikle yalnızca belirli locale koşulları altında ortaya çıkar ve tek bir dilde çalışan geliştiriciler tarafından gözden kaçabilir. İşte en yaygın hata kategorileri:

Metin Taşması ve Kırpma

Almanca çeviriler İngilizce karşılıklarından sıklıkla %30-40 daha uzundur. Fince bileşik kelimeler olağanüstü uzun olabilir. UI bileşenlerinizin sabit genişlikleri varsa, çevrilmiş metinler taşar ya da kesilir. İngilizce'de "Submit" etiketli bir buton, Almanca'da "Absenden" ya da Fince'de "Laheta" olabilir — her biri daha fazla yatay alan gerektirir.

Karakter Kodlama Sorunları

Aksan işaretli karakterler, CJK karakterleri veya emoji gibi ASCII aralığı dışındaki karakterler, uygulamanız tüm stack'te UTF-8'i tutarlı biçimde işlemiyorsa bozulabilir. Bu durum, veritabanı sütunlarını, API yanıtlarını, dosya kodlamasını ve HTML meta etiketlerini etkiler.

Tarih, Sayı ve Para Birimi Biçim Hataları

"3/4/2026" tarihi ABD'de 4 Mart anlamına gelirken Avrupa'nın büyük bölümünde 3 Nisan anlamına gelir. Sayı biçimlendirmesi de farklılık gösterir: ABD'deki "1,234.56" Almanya'da "1.234,56" olur. Para birimi simgeleri tutardan önce ya da sonra görünebilir. Hardcoded format string'leri bu hataların yaygın bir kaynağıdır.

Birleştirilmiş String'ler

"Sepetinizde " + count + " ürün var" gibi çevrilmiş parçaları birleştirerek cümle oluşturmak, farklı sözcük dizimine sahip dillerde bozulur. Japonca'da sayı genellikle cümlenin sonundaki fiilden önce gelir. Her zaman uygun çoğullama desteğiyle birlikte parametreli çeviri string'leri kullanın.

Locale Emülatörleri: Farklı Bölgeleri Simüle Etme

Bir locale emülatörü, gerçek sistem ayarlarınızı değiştirmeden uygulamanızın gördüğü dil, bölge ve biçimlendirme tercihlerini değiştirmenizi sağlar. Bu, test için son derece önemlidir; zira birden fazla işletim sistemi dili yükleyip aralarında geçiş yapmak, özellikle düzinelerce locale'da davranışı doğrulamanız gerektiğinde pratik değildir.

Tarayıcı Tabanlı Araçlar

Chrome DevTools Locale Override

Chrome'un yerleşik Sensors paneli, işletim sistemi ayarlarınızı değiştirmeden tarayıcı locale'ını geçersiz kılmanıza olanak tanır:

DevTools'u açın (F12 veya Cmd+Option+I)
Komut Menüsü'nü açmak için Cmd+Shift+P (veya Ctrl+Shift+P) tuşlarına basın
"Sensors" yazıp "Show Sensors"ı seçin
Sensors panelinde "Location" bölümünü bulun ve geçersiz kılma değerini ayarlayın
Accept-Language başlığını değiştirmek için chrome://settings/languages adresine gidin

Daha ayrıntılı kontrol için Chrome i18n extension API'si, extension'ların locale'a bağlı davranışları test etmesine olanak tanır.

Firefox Dil Ayarları

Firefox, basit locale test özellikleri sunar:

about:preferences adresine gidin
Genel bölümünde "Language"a inin
Tercih edilen dilleri ekleyip yeniden sıralamak için "Set Alternatives"a tıklayın
Firefox bunları Accept-Language başlığı olarak gönderir; sunucu tarafı locale algılamanız bunu kullanabilir

Tarayıcı Language Switcher Extension'ları

Chrome için "Locale Switcher" veya Firefox için "Quick Accept-Language Switcher" gibi extension'lar, her seferinde ayarlar arasında gezmek zorunda kalmadan locale'lar arasında hızlıca geçiş yapmanızı sağlar. Bunlar, özellikle birden fazla locale'ı hızlı biçimde kontrol etmeniz gereken geliştirme sürecinde oldukça kullanışlıdır.

OS Düzeyinde Locale Değiştirme

macOS

macOS'ta sistem dilini değiştirmeden uygulama başına locale testi yapabilirsiniz:

# Belirli bir locale ile uygulama başlatma
defaults write com.your.app AppleLanguages '("de")'

# Ya da web geliştirme için komut satırını kullanma
LANG=de_DE.UTF-8 open -a "Google Chrome"

System Settings > General > Language & Region bölümünde dil ekleyip öncelik sırasını ayarlamak için sürükleyebilirsiniz. Bu tüm uygulamaları etkiler ancak yeniden başlatma gerektirir.

Windows

Windows, sistem genelinde ve kullanıcı başına locale ayarları sunar:

Settings > Time & Language > Language & Region
Dil ekleyin ve görüntüleme dilini ayarlayın
"Regional format" altında tarih, saat ve sayı biçimlendirmesini bağımsız olarak değiştirin

Geliştiriciler için Set-WinUILanguageOverride PowerShell cmdlet'i, tam dil paketi kurulumu olmadan test yapılmasına olanak tanır.

Linux

Linux, en esnek locale kontrolünü sağlar:

# Mevcut locale'ları listeleme
locale -a

# Yeni bir locale oluşturma
sudo locale-gen fr_FR.UTF-8

# Belirli bir locale ile komut çalıştırma
LC_ALL=fr_FR.UTF-8 ./your-app

# Ayrı locale kategorilerini ayarlama
LC_TIME=ja_JP.UTF-8 LC_NUMERIC=de_DE.UTF-8 ./your-app

Linux'un LC_* ortam değişkenleri, locale kategorilerini (saat, sayısal, parasal, harmanlama) bağımsız olarak karıştırıp eşleştirmenize olanak tanır; bu da sınır durumlarını test etmek için kullanışlıdır.

Mobil Locale Emülasyonu

Android

Android Studio'nun emülatörü locale değiştirmeyi destekler:

Emülatörde Settings > System > Languages & input'a gidin
Dil ekleyin ve önceliği ayarlamak için sürükleyin
Betikli test için adb kullanın:

# adb aracılığıyla cihaz locale'ını değiştirme
adb shell setprop persist.sys.locale fr-FR
adb shell stop
adb shell start

Android ayrıca Android 13'ten (API 33) itibaren uygulama başına dil tercihlerini destekler; Settings > Apps > [Uygulama] > Language bölümünden yapılandırılabilir.

iOS

iOS Simulator, fiziksel bir cihaz olmadan locale değiştirmenizi sağlar:

Simulator'da Settings > General > Language & Region'a gidin
Cihaz dilini veya bölgesini değiştirin
Xcode şema tabanlı test için scheme'i düzenleyin > Run > Options > Application Language

Ayrıca komut satırından belirli bir locale ile simulator başlatabilirsiniz:

xcrun simctl boot "iPhone 15"
# Ardından Settings'te locale'ı değiştirin

Pseudo-Localization: Sorunları Erken Yakalama

Pseudo-localization, kaynak string'lerinizi — gerçek çeviriler gerektirmeden — çevrilmiş metnin özelliklerini simüle eden değiştirilmiş sürümlere dönüştüren bir test tekniğidir. Bu sayede çevirmenler çalışmalarını teslim etmeden çok önce, geliştirme sürecinde lokalizasyon hatalarını bulmanızı sağlar.

Pseudo-Localization Neden Değerlidir?

Gerçek çeviriler zaman alır ve maliyetlidir. Çeviriler gelene kadar beklerseniz ve ardından düzeninizin daha uzun metinlerle bozulduğunu ya da bazı string'lerin hardcoded olduğunu keşfederseniz, bu sorunları düzeltmek çok daha pahalı hâle gelir. Pseudo-localization, geliştirme sürecinde anında geri bildirim sağlar.

Pseudo-Localization Türleri

Aksan İşaretli Karakterler (Accented English)

ASCII karakterleri, metin okunabilirliğini koruyarak aksan işaretli Unicode karşılıklarıyla değiştirir:

Orijinal:  "Save changes"
Aksan:     "[Save changes]"

Bu yöntem, hardcoded string'leri (dönüştürülmeyecekler) ve kodlama sorunlarını (ASCII dışı karakterleri işleyemeyen sistemler bozulacak) yakalar.

Genişletilmiş Metin (String Elongation)

Çeviride oluşan metin genişlemesini simüle etmek için string'lere dolgu ekler:

Orijinal:   "Submit"
Genişletilmiş: "[Suuuubmiiiiit xxxxxxxxx]"

Yaygın bir yaklaşım, Almanca, Fransızca veya Fince gibi dilleri simüle etmek için metni %30-40 oranında genişletmektir. Bu yöntem, düzen taşma sorunlarını, kırpma problemlerini ve sabit genişlikli container'ları yakalar.

Yansıtılmış Metin (RTL Simulation)

Sağdan sola yazı sistemlerini simüle etmek için string'i tersine çevirir ve isteğe bağlı olarak RTL Unicode işaretçileri ekler:

Orijinal:   "Hello World"
Yansıtılmış: "dlroW olleH"

Bu, düzeninizin metin yönü değişikliklerini ele alıp almadığına dair hızlı bir görsel kontrol sağlar; ancak gerçek Arapça veya İbranice içerikle yapılan tam RTL testinin yerini tutmaz.

Pseudo-Localization Araçları

pseudolocale (npm)

Pseudo-localize edilmiş string'ler üretmek için hafif bir Node.js kütüphanesi:

import { str } from 'pseudolocale';

str('Hello World');
// Çıktı: "[Heello Woorld xxxxxxxxx]"

str('Hello World', { strategy: 'bidi' });
// Çıktı: RTL işaretli sürüm

ICU MessageFormat Pseudo-Localization

Birçok i18n kütüphanesinin desteklediği ICU MessageFormat kullanıyorsanız, parametre yer tutucularını koruyarak pseudo-localization'ı mesaj düzeyinde uygulayabilirsiniz:

Orijinal: "Welcome, {name}! You have {count} messages."
Pseudo:   "[Weelcoomee, {name}! Yoouu haavee {count} meessaagees. xxxxxxxxx]"

{name} ve {count} yer tutucuları olduğu gibi kalır; böylece uygulama pseudo-localize edilmiş string'lerle normal şekilde çalışmaya devam eder.

Yerleşik Framework Desteği

Bazı i18n framework'leri pseudo-localization özelliklerini bünyesinde barındırır. Örneğin Android Studio, ek araç gerekmeden etkinleştirebileceğiniz yerleşik bir pseudo-locale'a sahiptir (en-XA aksan işaretli, ar-XB RTL için). Web framework'leri için pseudo-localization'ı ek bir locale olarak çeviri iş akışınıza entegre edebilirsiniz.

RTL (Sağdan Sola) Testi

Arapça, İbranice, Farsça ve Urduca gibi sağdan sola yazılan diller, yalnızca metin çevirisinden fazlasını gerektirir. Tüm kullanıcı arayüzü düzeninin yansıtılması gerekir: navigasyon sağ tarafa geçer, metinler sağa hizalanır, ilerleme çubukları sağdan sola dolar ve simgelerin yönü değişmesi gerekebilir.

Web Uygulamalarında Yaygın RTL Sorunları

Düzen Yansıtma Hataları

margin-left, padding-right, text-align: left ve float: left gibi CSS özellikleri için RTL karşılıkları gerekmektedir. Modern CSS mantıksal özellikleri bunu daha zarif biçimde çözer:

/* Fiziksel özellikler (RTL için sorunlu) */
.sidebar {
  margin-left: 20px;
  padding-right: 16px;
  text-align: left;
}

/* Mantıksal özellikler (RTL için güvenli) */
.sidebar {
  margin-inline-start: 20px;
  padding-inline-end: 16px;
  text-align: start;
}

Çift Yönlü Metin (Bidi) Sorunları

RTL metin, İngilizce marka adları, URL'ler veya sayılar gibi gömülü LTR içerik barındırdığında, Unicode Bidirectional Algorithm görüntüleme sırasını belirler. Bu durum, özellikle noktalama işaretleri ve karma yönlü cümlelerde beklenmedik sonuçlar doğurabilir.

Simge Yönü

Oklar, "geri" düğmeleri, ilerleme göstergeleri ve liste madde işaretleri gibi yönlü simgelerin RTL düzenlerinde çevrilmesi gerekir. Oysa oynat/durdur, ses, telefon gibi evrensel simgeler çevrilmemelidir. Resim ve videolar gibi medya içerikleri de genellikle yansıtılmamalıdır.

RTL Test Stratejileri ve Araçları

dir="rtl" Özelliği

Web uygulamalarında RTL testi için en basit başlangıç noktası:

<html dir="rtl" lang="ar">

Belirli bölümleri test etmek için yönü bileşen düzeyinde de ayarlayabilirsiniz:

<div dir="rtl">
  <!-- Bu bölüm RTL olarak render edilecektir -->
</div>

Stylelint RTL Plugin

stylelint-no-physical-properties plugin'i, mantıksal karşılıklarıyla değiştirilmesi gereken fiziksel CSS özelliklerini işaretler:

{
  "plugins": ["stylelint-no-physical-properties"],
  "rules": {
    "plugin/no-physical-properties": true
  }
}

RTLCSS

RTLCSS, LTR CSS'yi otomatik olarak RTL'ye dönüştürür. Build pipeline'ınıza entegre edilebilir:

import rtlcss from 'rtlcss';

const rtlCSS = rtlcss.process(originalCSS);

Tarayıcıda Test

Tüm büyük tarayıcılar dir özelliğini ve CSS direction özelliğini destekler. Kod değişikliği yapmadan hızlı görsel test için tarayıcı DevTools'unu kullanarak <html> öğesinde yönü değiştirebilirsiniz.

Otomatik Lokalizasyon Testi

Uygulamanız büyüdükçe her locale'ı manuel olarak test etmek sürdürülemez hâle gelir. Otomatik lokalizasyon testi, sorunları tutarlı biçimde yakalamak amacıyla CI/CD pipeline'ınıza entegre olur.

Screenshot Karşılaştırma Testi

Görsel regresyon testi, uygulamanızın farklı locale'lardaki ekran görüntülerini alır ve bunları temel görüntülerle karşılaştırır. Playwright, Cypress ve Percy bu iş akışını destekler:

// Playwright örneği: birden fazla locale'da ekran görüntüsü alma
import { test, expect } from '@playwright/test';

const locales = ['en', 'de', 'ja', 'ar'];

for (const locale of locales) {
  test(`anasayfa ${locale} locale'ında doğru render ediliyor`, async ({ page }) => {
    await page.goto(`/${locale}`);
    await expect(page).toHaveScreenshot(`homepage-${locale}.png`, {
      fullPage: true,
    });
  });
}

Bu yaklaşım, yalnızca unit testlerle tespit edilmesi güç olan metin taşmalarını, düzen kaymalarını ve RTL yansıtma sorunlarını yakalar.

String Doğrulama

Çeviri tamlığı ve doğruluğu için otomatik kontroller:

// Örnek: tüm locale dosyalarının eşleşen anahtarlara sahip olduğunu doğrulama
import { readdirSync, readFileSync } from 'fs';

function validateTranslationKeys(localeDir) {
  const files = readdirSync(localeDir).filter(f => f.endsWith('.json'));
  const baseKeys = Object.keys(
    JSON.parse(readFileSync(`${localeDir}/en.json`, 'utf-8'))
  );

  const results = [];

  for (const file of files) {
    const locale = file.replace('.json', '');
    const translations = JSON.parse(
      readFileSync(`${localeDir}/${file}`, 'utf-8')
    );
    const translatedKeys = Object.keys(translations);

    const missing = baseKeys.filter(k => !translatedKeys.includes(k));
    const extra = translatedKeys.filter(k => !baseKeys.includes(k));

    results.push({ locale, missing, extra });
  }

  return results;
}

Bu yöntem, eksik çevirileri, sahipsiz anahtarları ve locale dosyaları arasındaki yapısal tutarsızlıkları yakalar.

Genişletilmiş Metinle Düzen Testi

Taşma sorunlarını yakalamak için pseudo-localization'ı otomatik düzen testiyle birleştirin:

// Vitest örneği: hiçbir öğenin container'ından taşmadığını kontrol etme
import { describe, it, expect } from 'vitest';
import { render } from '@testing-library/react';
import { IntlProvider } from 'react-intl';
import { pseudoLocalize } from './test-utils';

describe('Genişletilmiş metinle düzen', () => {
  it('%40 genişletilmiş string\'lerle taşmamalıdır', () => {
    const expandedMessages = pseudoLocalize(baseMessages, {
      expansion: 1.4,
    });

    const { container } = render(
      <IntlProvider locale="en" messages={expandedMessages}>
        <MyComponent />
      </IntlProvider>
    );

    const elements = container.querySelectorAll('*');
    for (const el of elements) {
      expect(el.scrollWidth).toBeLessThanOrEqual(el.clientWidth + 1);
    }
  });
});

CI/CD Entegrasyonu

CI/CD pipeline'ınızdaki kapsamlı bir lokalizasyon test aşaması şunları içerebilir:

Statik analiz: Hardcoded string'ler için lint kontrolü, kullanıcıya yönelik tüm metinlerin i18n sistemi üzerinden geçtiğini doğrulama
Anahtar doğrulama: Tüm locale'ların eksik anahtar olmaksızın tam çevirilere sahip olduğunu doğrulama
Pseudo-locale build: Uygulamayı pseudo-localize edilmiş string'lerle derleyin ve düzen testlerini çalıştırın
Görsel regresyon: Hedef locale'larda ekran görüntüsü alın ve karşılaştırın
RTL snapshot testleri: Özellikle Arapça ve İbranice locale'larda RTL düzenini doğrulayın

# Örnek GitHub Actions iş akışı adımı
localization-tests:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - name: Bağımlılıkları yükle
      run: npm ci
    - name: Çeviri anahtarlarını doğrula
      run: npm run test:i18n-keys
    - name: Pseudo-locale düzen testlerini çalıştır
      run: npm run test:pseudo-locale
    - name: Görsel regresyon testleri
      run: npx playwright test --project=i18n-visual

better-i18n, L10n Testine Nasıl Yardımcı Olur?

Yukarıdaki araçlar lokalize edilmiş içeriğin render ve düzenini test etmeye odaklanırken, better-i18n çeviri sorunlarını kaynağında yakalamanıza yardımcı olur. Platform, çeviri kapsama takibi sunar; böylece her locale için hangi anahtarların çevirisi eksik, tek bakışta görebilirsiniz. Bu, gerçek zamanlı bir kontrol paneli görünümü sağlayarak otomatik anahtar doğrulama testlerinizi tamamlar.

Better i18n'in anahtar yönetimi özellikleri, kullanılmayan anahtarları işaretler ve kaynak string'lerine karşılık gelen çeviri eklenmeden yeni string eklendiğinde sizi uyarır. Geliştirme iş akışınıza entegre edildiğinde bu, erken uyarı sistemi işlevi görür — çeviri boşluklarını production'da hata olmadan önce tespit edebilirsiniz.

Platformun yayımlama iş akışı da tutarlılığı korumaya yardımcı olur: çeviriler, eksik veya hatalı çevirilerin canlı uygulamanıza ulaşma olasılığını azaltarak bir inceleme ve yayımlama döngüsünden geçer.

SSS

Pseudo-localization nedir ve neden kullanmalıyım?

Pseudo-localization, gerçek çevirilerin özelliklerini — artan metin uzunluğu, aksan işaretli karakterler ve sağdan sola metin yönü gibi — simüle eden değiştirilmiş sürümlerle çevrilebilir string'lerin yerini alan bir yazılım test tekniğidir. Kullanmanız gerekir çünkü gerçek çeviriler mevcut olmadan, geliştirme sürecinde lokalizasyon hatalarını (metin taşması, hardcoded string'ler ve kodlama hataları gibi) yakalar. Bu, düzen ve internationalization sorunlarını düzeltmenin en ucuz olduğu erken aşamada tespit ederek zaman ve para tasarrufu sağlar.

Web uygulamamda RTL dillerini nasıl test ederim?

HTML root öğenize dir="rtl" ekleyerek düzeninizi görsel olarak incelemeye başlayın. Fiziksel CSS özelliklerini (margin-left, padding-right) mantıksal karşılıklarıyla (margin-inline-start, padding-inline-end) değiştirin. CSS dönüşümünü otomatikleştirmek için RTLCSS gibi araçlar, mantıksal özellikleri zorlamak için stylelint plugin'leri kullanın. Çift yönlü metin (bidi) sorunlarını yakalamak için yalnızca yansıtılmış İngilizce değil, gerçek Arapça veya İbranice içerikle test edin. Son olarak, gerilemeleri önlemek için CI/CD pipeline'ınıza RTL locale'ları için görsel regresyon testleri ekleyin.

En yaygın lokalizasyon hataları nelerdir?

En yaygın lokalizasyon hataları şunlardır: çevirilerin kaynak dilden daha uzun olması durumunda metin taşması veya kırpma (özellikle Almanca, Fince ve Fransızca); ASCII dışı karakterlerle (aksan işaretli harfler, CJK, emoji) karakter kodlama hataları; hardcoded biçim kalıplarından kaynaklanan hatalı tarih, saat ve sayı biçimlendirmesi; parametreli çeviriler yerine string birleştirmeden kaynaklanan bozuk cümleler; kullanıcı arayüzünün düzgün şekilde yansıtılmadığı RTL dillerindeki düzen hataları ve çevrilmemiş anahtarların kullanıcılara ham anahtar adları veya fallback metin olarak gösterildiği eksik çeviriler.

Çok Dilli Uygulamalar İçin Locale Emülatörleri ve Test Araçları