Çoklu Dil ve Lokalizasyon (i18n/l10n) Rehberi [2026]

i18n ve l10n: Temel Kavramlar

Yazilim urunlerini birden fazla dilde ve kulturde sunmak, global pazarlara erisimin on kosuludur. Bu surecte iki temel kavram birbirinden ayrilmalidir: internationalization (i18n) ve localization (l10n).

Internationalization, yazilimin birden fazla dili ve kulturu destekleyebilecek sekilde tasarlanmasi ve gelistirilmesidir. Kodun dilden bagimsiz hale getirilmesi, tarih/saat/sayi formatlarinin yerellestirilmeye hazir olmasi ve kullanici arayuzunun farkli metin uzunluklarina uyum saglayabilmesi i18n kapsamindadir. Kisaca i18n, urunun coklu dil destegine "hazir" hale getirilmesidir.

Localization ise belirli bir dil ve kultur icin icerik uyarlamanin gerceklestirilmesidir. Ceviri, tarih formati ayarlama, para birimi donusumu ve kulturel uyarlama l10n surecinin parcalaridir. i18n altyapiyi hazirlar, l10n bu altyapi uzerine belirli bir dil ve kultur icin somut icerigi yerlestirir.

Bu ayrimin erken asamada dogru yapilmasi kritiktir. i18n sonradan eklemek, kodun buyuk bolumunun yeniden yapilandirilmasini gerektirebilir. Sabit kodlanmis string'lerin cikarilmasi, tarih formatlama mantikinin degistirilmesi ve arayuz duzeni ayarlamalarinin yapilmasi ciddi refactoring maliyeti olusturur. Bu nedenle, urunun birden fazla dilde sunulma ihtimali varsa, i18n altyapisi basindan itibaren kurulmalidir.

Unicode ve UTF-8 Temelleri

Coklu dil desteginin teknik temeli, karakter kodlamasinda yatar. Unicode, dunyadaki tum yazim sistemlerindeki karakterleri tek bir standartta birlestiren evrensel karakter setidir. 150.000'den fazla karakteri kapsayan Unicode, Latin, Kiril, Arap, Cin, Japon ve diger tum yazim sistemlerini destekler. UTF-8 ise Unicode karakterlerini kodlayan en yaygin kullanilan kodlama bicimidir.

UTF-8, ASCII ile geriye donuk uyumludur ve degisken uzunluklu kodlama kullanir. Ingilizce karakterler tek bayt ile temsil edilirken, Turkce karakterler (o, u, c, g, i, s) iki bayt, Arapca ve Cince karakterler uc veya dort bayt kullanir. Bu degisken uzunluk, depolama acisindan verimli olurken, string islemleri acisindan dikkat gerektirir.

Veritabani, API, dosya sistemi ve kullanici arayuzu dahil tum katmanlarda tutarli UTF-8 kullanimi saglanmalidir. Veritabaninda MySQL kullaniliyorsa, utf8mb4 karakter seti tercih edilmelidir; standart utf8 seti yalnizca 3 baytlik karakterleri destekler ve bazi Unicode karakterlerini (emoji dahil) saklayamaz. PostgreSQL varsayilan olarak UTF-8 kullanir ve bu konuda ek yapilandirma gerektirmez.

String islemlerinde bayt uzunlugu ile karakter uzunlugu arasindaki fark goz onunde bulundurulmalidir. Turkce "guzel" kelimesi 6 karakter ancak UTF-8'de 7 bayt yer kaplar. Ayrica grapheme cluster kavrami da onemlidir; bazi karakterler birden fazla Unicode code point'ten olusur (ornegin bayrak emojileri). String kesme, karsilastirma ve siralama islemlerinde Unicode-aware fonksiyonlar ve locale-specific collation kullanimalidir.

ICU Message Format

International Components for Unicode (ICU), coklu dil destegi icin kapsamli bir kutuphane ve mesaj format standardidir. ICU Message Format, ceviri metinlerindeki degisken, cogullama ve secim ifadelerini standart bir sozdizimi ile tanimlar ve cevirmenler icin anlasilir bir yapi sunar.

Degisken Yerlestirme

Basit degisken yerlestirme, ceviri metinlerinde dinamik degerlerin konumlandirilmasini saglar. Ornegin "Merhaba {name}, {count} yeni mesajiniz var" seklinde tanimlanan bir mesaj sablonu, farkli dillerde degisken siralamasinin farkli olmasi durumunda bile dogru calisir. Cevirmen degiskenlerin sirasini dilinin gramerine uygun sekilde duzenleyebilir. String birlestirme (concatenation) yerine degisken yerlestirme kullanmak, ceviri kalitesini onemli olcude arttirir.

Cogullama (Pluralization)

Cogullama kurallari diller arasinda buyuk farkliliklar gosterir. Ingilizce yalnizca tekil ve cogul ayirimi yaparken (one/other), Arapca alti farkli cogullama kategorisi icerir (zero, one, two, few, many, other). Lehce ve Rusca gibi Slav dillerinde de karmasik cogullama kurallari vardir. Turkce'de cogullama goreceli olarak basittir ancak yine de dogru ele alinmalidir.

ICU Message Format, plural ifadesi ile dile ozgu cogullama kurallarini destekler. CLDR (Common Locale Data Repository) veritabani, her dil icin cogullama kurallarini tanimlar. Bu sayede her dil icin grammatik olarak dogru cogul formlar uretilir. Sabit kodlanmis cogullama mantigi yerine ICU kurallarinin kullanilmasi, yeni dil eklemeyi kolaylastirir ve grammatik hatalari onler.

Secim Ifadeleri

Cinsiyet, kategori veya diger degiskenlere gore farkli mesaj varyantlari gosterilmesi gerektigi durumlarda select ifadesi kullanilir. Ornegin, kullanicinin cinsiyetine gore "O profilini guncelledi" seklinde farkli mesajlar gosterilebilir. Ic ice (nested) ifadelerle karmasik senaryolar da ele alinabilir; ornegin hem cinsiyet hem de cogullama kurallarini birlestiren mesajlar tanimlanabilir.

Tarih, Saat, Sayi ve Para Birimi Formatlama

Tarih, saat, sayi ve para birimi formatlari kulturler arasinda onemli farkliliklar gosterir. Bu formatlarin dogru uygulanmasi, kullanici deneyiminin kalitesini dogrudan etkiler ve profesyonel bir izlenim birakir.

Tarih ve Saat

Turkiye'de "06.03.2026" olarak yazilan tarih, ABD'de "03/06/2026", Japonya'da "2026/03/06" olarak gosterilir. Saat formati olarak 24 saat ve 12 saat (AM/PM) tercihleri kulturlere gore degisir. Haftanin ilk gunu bazi kulturlerde Pazartesi, bazlarinda Pazar'dir; bu farklilik takvim bilesenlerin goruntulenmesini etkiler.

JavaScript'te Intl.DateTimeFormat API'si, tarayici tarafinda yerellestirilmis tarih formatlama saglar. Backend tarafinda ise moment.js'in yerini alan Day.js veya date-fns kutuphaneleri yerellestirilmis formatlama destegi sunar. Temporal API, JavaScript'in yakin gelecekte standart tarih/saat isleme cozumu olarak Intl ile entegre calisacaktir.

Zaman dilimi yonetimi, tarih/saat lokalizasyonunun en karmasik yonudur. Tarih/saat verilerinin UTC olarak saklanmasi ve gosterim sirasinda kullanicinin zaman dilimine donusturulmesi standart yaklasimdir. Yaz saati uygulamasi gecisleri ve tarihsel zaman dilimi degisiklikleri icin IANA zaman dilimi veritabaninin kullanilmasi gerekir.

Sayi ve Para Birimi

Ondalik ayiraci (nokta vs virgul), binlik ayiraci (nokta, virgul, bosluk) ve para birimi gosterimi kulturlere gore degisir. Turkiye'de "1.234.567,89 TL" olarak yazilan deger, ABD'de "$1,234,567.89", Almanya'da "1.234.567,89 EUR" olarak gosterilir. Intl.NumberFormat API'si bu farkliliklari otomatik olarak ele alir. Para birimi sembolunun konumu (on veya arka), negatif deger gosterimi ve yuzde formati da kulturel farkliliklari yansitir.

RTL Dil Destegi

Arapca, Ibranice ve Farsca gibi sadan sola (RTL) yazilan diller, ozel arayuz duzeni gerektirir. RTL destegi yalnizca metin yonunu degistirmekle sinirli degildir; tum sayfa duzeninin yansitilmasi (mirroring) gerekir. Navigasyon menuleri, form elemanlari, ilerleme cubukları ve kaydirma yonleri yansitilmalidir.

CSS ile RTL Yonetimi

CSS logical properties, RTL uyumu icin en modern ve etkili yaklasimdir. margin-left yerine margin-inline-start, padding-right yerine padding-inline-end gibi mantiksal ozellikler kullanildiginda, tarayici metin yonune gore dogru tarafi otomatik olarak belirler. Bu yaklasim, ayri RTL stil dosyasi olusturma ihtiyacini buyuk olcude ortadan kaldirir.

Flexbox ve CSS Grid gibi modern layout sistemleri, direction ozelligine gore otomatik yansitma yapar. Ancak yonsel ikonlar (oklar, yon isaretleri), bazi gorseller (ekran goruntuleri, diyagramlar), animasyon yonleri ve kutucuk golgelerinin yonleri icin ek ayarlamalar gerekebilir. Bidirectional (bidi) metin senaryolarinda, ayni cumle icinde hem LTR hem RTL metin bulunabilir; bu durumlar icin Unicode bidi algoritmasi ve HTML bdi/bdo elementleri kullanilir.

dir ve lang Nitelikleri

HTML'de dir="rtl" niteligi metin yonunu, lang niteligi ise dil bilgisini belirtir. Bu niteliklerin HTML etiketinde dogru ayarlanmasi, tarayicinin metin islemesini, otomatik heceleme davranisini, ekran okuyucu telaffuzunu ve form eleman yonlendirmesini etkiler.

Ceviri Yonetim Platformlari

Ceviri surecinin verimli yonetilmesi, coklu dil desteginin surdurulebilirligi icin kritiktir. Manuel dosya paylasimi ve e-posta tabanli ceviri surecleri, olcek buyudukce yonetilemez hale gelir ve tutarsizliklara yol acar.

Platformlar

Crowdin, Lokalise ve Phrase (eski adiyla PhraseApp), yazilim lokalizasyonu icin ozellestirilmis ceviri yonetim platformlaridir. Bu platformlar ceviri bellegi (translation memory), terminoloji yonetimi (glossary), otomatik ceviri onerileri, dallama (branching), ekran goruntuleri ile baglam saglama ve CI/CD entegrasyonu gibi ozellikler sunar.

Ceviri bellegi, daha once cevrilen ifadelerin yeniden kullanilmasini saglayarak tutarlilik ve verimlilik artisi sunar. Yuzde 100 eslesmelerde otomatik ceviri uygulanabilir, benzer ifadeler icin oneri sunulur. Makine cevirisi entegrasyonu (Google Translate, DeepL, ChatGPT), cevirmenler icin baslangic noktasi olusturarak ceviri suresini onemli olcude kisaltir. Ancak makine cevirisinin profesyonel cevirmen tarafindan gozden gecirilmesi (post-editing) kalite icin gereklidir.

Gelistirici Is Akisi

Ideal bir ceviri is akisinda, gelistirici kaynak kodu icinde ceviri anahtarlarini kullanir, string extraction araci ile yeni anahtarlar otomatik olarak tespit edilir, anahtarlar ceviri platformuna aktarilir, cevirmenler platform uzerinde baglam bilgisiyle birlikte ceviri yapar ve tamamlanan ceviriler otomatik olarak kod deposuna pull request olarak geri cekilir. Bu akisin CI/CD pipeline'ina entegre edilmesi, eksik ceviri kontrolu, format dogrulama ve ceviri kalite metrikleri gibi kalite guvence adimlarini otomatiklestirir.

Frontend'de i18n: React Ekosistemi

React uygulamalarinda i18n icin bircok olgun kutuphane mevcuttur. Secim, projenin gereksinimlerine ve kullanilan framework'e gore sekillenmelidir.

react-intl (FormatJS)

FormatJS ailesinin bir parcasi olan react-intl, ICU Message Format destegi ile guclu bir i18n cozumu sunar. FormattedMessage bilesen ve useIntl hook'u ile bilesen tabanli ceviri yonetimi saglar. Tarih, sayi ve cogullama formatlama ozellikleri yerlesik olarak gelir. ICU Message Format'in tam destegi, karmasik ceviri senaryolarini dogru sekilde ele almaya olanak tanir.

next-intl

Next.js uygulamalari icin ozel olarak tasarlanan next-intl, App Router ile uyumlu calisir ve sunucu bilesenlerinde i18n destegi saglar. Middleware tabanli dil algilama, yerellestirilmis URL yonlendirmesi ve statik site olusturma destegi ile Next.js ekosistemine dogal olarak entegre olur. Server component'lerde ceviri kullanimi, istemci tarafina gonderilen JavaScript boyutunu azaltarak performans avantaji saglar.

i18next ve react-i18next

i18next, dil bagimsiz bir i18n framework'u olup react-i18next ile React entegrasyonu saglar. Namespace destegi, lazy loading, interpolasyon ve cogullama ozellikleri ile esnek bir yapi sunar. Buyuk uygulamalarda ceviri dosyalarinin namespace'lere bolunmesi, performans ve yonetim acisindan avantaj saglar. Yalnizca aktif sayfanin cevirilerinin yuklenmesi, baslangic yukleme suresini iyilestirir. Plugin mimarisi sayesinde backend entegrasyonlari, dil algilama ve onbellek mekanizmalari genisletilebilir.

Backend'de i18n

Backend tarafinda i18n, API yanitlari, e-posta sablonlari, hata mesajlari, bildirim icerikleri ve PDF rapor olusturma gibi sureclerin yerellestirilmesini kapsar.

Node.js: i18next

i18next'in backend versiyonu, dosya sistemi, veritabani veya uzak kaynaklardan ceviri yuklemesini destekler. Express veya Fastify middleware'i ile HTTP istegindeki Accept-Language basligina gore otomatik dil secimi yapilabilir. E-posta sablonlarinin farkli dillerde render edilmesi icin i18next'in goruntu motoru (template engine) entegrasyonu kullanilabilir.

Python: gettext ve Babel

Python ekosisteminde gettext standart ceviri sistemidir. Django'nun yerlesik i18n destegi gettext uzerine kuruludur ve template etiketleri ile ceviri, URL lokalizasyonu ve form dogrulama mesajlarinin yerellestirilmesini kapsar. Babel kutuphanesi ise tarih, sayi ve para birimi formatlama icin kapsamli yerellestirilme destegi saglar. Flask-Babel ve Django'nun i18n middleware'i dil secimini HTTP basliklarindan veya URL yapisindan otomatik olarak belirler.

API Tasarimi

Coklu dil destekli API'larda dil tercihi, Accept-Language basligi, URL parametresi veya kullanici profil ayarlari uzerinden belirlenir. API yanitlarinda yerellestirilmis icerik dondurmek mi yoksa istemci tarafinda yerelleştirme yapmak mi daha uygun oldugu, kullanim senaryosuna gore degerlendirilmelidir. Hata mesajlari ve dogrulama yanitlari genellikle sunucu tarafinda yerellestirilir, sabit arayuz metinleri ise istemci tarafinda yonetilir.

Veritabani Semasi: Coklu Dil Icerigi

Coklu dil iceriginin veritabaninda nasil saklanacagi, veri modeli tasariminin kritik bir kararidir. Uc temel yaklasim degerlendirilebilir.

Sutun Bazli Yaklasim

Her dil icin ayri sutunlar (title_tr, title_en, title_de) basit ve sorgulmasi kolay bir yaklasimdir ancak yeni dil eklemek sema degisikligi gerektirir. Az sayida dili destekleyen ve dil sayisinin sabit oldugu sistemler icin uygundur. Sorgularda JOIN gerektirmez, bu da performans acisindan avantaj saglar.

Ayri Ceviri Tablosu

Ana tablo ile ceviri tablosu arasinda iliski kurulmasi, en esnek yaklasimdir. products tablosu dil bagimsiz alanlari (fiyat, stok, olusturma tarihi), product_translations tablosu ise dile ozgu alanlari (baslik, aciklama, slug) icerir. Yeni dil eklemek sema degisikligi gerektirmez. Ancak sorgular JOIN islemleri nedeniyle daha karmasik hale gelir; bu durumda veritabani gorunumleri (views) veya ORM katmaninda soyutlama kullanarak sorgu karmasikligini azaltmak mumkundur.

Smart Maple olarak uzerinde calistigimiz projelerde, genellikle ayri ceviri tablosu yaklasimini oneriyoruz. Bu yaklasim, dil sayisi arttikca sema degisikligi gerektirmemesi ve temiz veri modeli saglamasi nedeniyle uzun vadede en surdurulebilir secenektir.

JSON Sutunu

PostgreSQL'in jsonb veya MongoDB'nin yerlesik JSON destegi ile ceviri verileri tek bir sutunda saklanabilir. Bu yaklasim sema esnekligi saglar ve ek tablo gerektirmez. Ancak belirli bir dildeki icerige indeks olusturma (PostgreSQL'de jsonb expression index ile mumkun), sorgulama performansi ve veri butunlugu kısıtlamalari acisindan sinirliliklar tasir. Kucuk ve orta olcekli projelerde pragmatik bir secim olabilir.

URL Stratejisi

Coklu dil destekli web sitelerinde URL yapisi, hem kullanici deneyimini hem de SEO performansini etkiler.

Alt Alan (Subdomain)

tr.example.com, en.example.com seklinde her dil icin ayri alt alan kullanilir. Her alt alan bagimsiz olarak yapilandirilabilir ve farkli sunucularda barindirmak mumkun olabilir. Ancak DNS ve SSL sertifika yonetimi ek karmasiklik getirir. Domain otoritesinin alt alanlar arasinda bolunmesi SEO acisindan dezavantaj olusturabilir.

Yol Oneki (Path Prefix)

example.com/tr/, example.com/en/ seklinde URL yoluna dil oneki eklenir. Tek alan adi ve SSL sertifikasi yeterlidir, uygulamasi basittir ve cogu proje icin onerilen yaklasimdir. Domain otoritesi tek alanda toplanir. Next.js, Nuxt ve benzeri framework'ler bu yapiyi yerlesik olarak destekler. Varsayilan dil icin ons eki atlamak (example.com/ = Turkce) veya tutarlilik icin tum dillerde onek kullanmak (example.com/tr/) arasinda bir tasarim karari verilmelidir.

Sorgu Parametresi

example.com?lang=tr seklinde sorgu parametresi kullanilir. SEO acisindan en zayif yaklasimdir ve genellikle onerilmez. Arama motorlari, farkli dil versiyonlarini ayri sayfalar olarak dizinlemekte zorlanabilir. Yalnizca dahili araclar veya API'lar icin tercih edilebilir.

SEO: hreflang ve Coklu Dil

Coklu dil web sitelerinin arama motorlarinda dogru sekilde dizinlenmesi icin hreflang etiketlerinin dogru uygulanmasi kritiktir. Yanlis yapilandirma, yanlis dil versiyonunun arama sonuclarinda gosterilmesine yol acar.

hreflang Uygulamasi

Her sayfanin HTML basliginda veya sitemap'te, o sayfanin diger dil versiyonlarina yonelik hreflang etiketleri eklenir. Bu etiketler arama motorlarina hangi sayfanin hangi dil ve bolge icin oldugunu bildirir. Ornegin, Turkce versiyonu icin hreflang="tr", Almanca versiyonu icin hreflang="de" ve varsayilan versiyon icin hreflang="x-default" kullanilir. Her sayfanin kendi kendisine referans (self-referencing) hreflang etiketi de bulunmalidir. Hreflang iliskilerinin cift yonlu olmasi gerekir; A sayfasi B'yi gosteriyorsa, B de A'yi gostermelidir.

Icerik Tutarliligi

Her dil versiyonunun benzersiz ve kaliteli icerige sahip olmasi SEO acisindan onemlidir. Otomatik ceviri ile olusturulmus dusuk kaliteli icerik, arama motoru siralamalarini olumsuz etkileyebilir. Ceviri kalite kontrol sureclerinin olusturulmasi ve profesyonel cevirmenlerin katilimi, uzun vadede SEO basarisini destekler. Icerik stratejisi olarak tum iceriklerin tum dillere cevrilmesi yerine, hedef pazar analizine dayali secici ceviri yaklasimlari da degerlendirilmelidir.

Canonical URL ve Sitemap

Her dil versiyonu icin ayri canonical URL tanimlanmali ve coklu dil sitemap'i olusturulmalidir. Sitemap'te her URL'nin dil varyantlari xhtml:link etiketleriyle belirtilir. Buyuk sitelerde sitemap index dosyalari ile yapinin yonetilmesi ve sitemap'lerin otomatik olusturulmasi icin build surecleriyle entegrasyon saglanmalidir.

Kulturel Uyarlama: Cevirinin Otesi

Lokalizasyon yalnizca dil cevirisinden ibaret degildir. Gercek anlamda yerellestirilmis bir urun, hedef kulturun normlarini, beklentilerini ve hassasiyetlerini yansitir. Kulturel uyarlama, urunun hedef pazarda dogal ve tanidik hissettirmesini saglar.

Gorsel ve Renk Uyarlama

Gorsellerdeki kisiler, mekanlar ve kulturel ogeler hedef kitleye uygun olmalidir. Renkler farkli kulturlerde farkli anlamlar tasiyabilir; ornegin kirmizi renk Cin'de sans ve refahi, bazi bati kulturlerinde ise tehlike ve duraklama isaret eder. Yesil renk Islam kulturlerinde ozel bir oneme sahipken, bazi Guney Amerika ulkelerinde farkli cagrisimlar yapabilir. Ikonlar ve semboller de kulturel baglamda degerlendirilmelidir; posta kutusu ikonu ulkelere gore farkli gorunumlere sahiptir.

Adres ve Telefon Formatlari

Adres yapilari ulkeler arasinda buyuk farkliliklar gosterir. Posta kodu uzunlugu ve formati (Turkiye: 5 haneli sayi, Ingiltere: alfanumerik), bolge/il/eyalet hiyerarsisi, telefon numarasi formati (ulke kodu, alan kodu, numara uzunlugu) ve isim soyisim sirasi (Dogu Asya kulturlerinde soyisim once gelir) gibi farkliliklar, form tasarimi ve veri dogrulama mantigi acisindan dikkate alinmalidir. libphonenumber gibi kutuphaneler, telefon numarasi dogrulama ve formatlama icin kapsamli destek saglar.

Yasal ve Regulatif Farkliliklar

Gizlilik politikalari, kullanim kosullari, cerez onay mekanizmalari ve vergi hesaplamalari ulkeler arasinda farklilik gosterir. AB'de GDPR gereksinimleri, Turkiye'de KVKK uyumu, Kaliforniya'da CCPA gereksinimleri gibi bolgesel regulasyonlarin lokalizasyon surecine dahil edilmesi, yerel mevzuata uyumu saglar. Odeme yontemleri de bolgesel farkliliklar gosterir; Turkiye'de kredi karti taksitler yayginken, Almanya'da banka havalesi (SEPA) ve Hollanda'da iDEAL tercih edilen yontemlerdir.

Sonuc

Coklu dil ve lokalizasyon, yazilim urunlerinin global pazarlara erisimini saglayan stratejik bir yetenektir. i18n altyapisinin projenin erken asamalarinda kurulmasi, sonradan yasanacak buyuk refactoring maliyetlerini onler.

Unicode ve UTF-8 temelleri, ICU Message Format, dogru ceviri yonetim surecleri ve kulturel uyarlama, basarili bir lokalizasyon stratejisinin temel bilesenlerini olusturur. URL stratejisi ve hreflang gibi SEO bilesenleri ise coklu dil icerigin arama motorlarinda dogru sekilde dizinlenmesini saglar.

Veritabani semasi secimi, frontend ve backend i18n kutuphaneleri ve ceviri is akisi otomasyonu gibi teknik kararlarin dogru alinmasi, coklu dil desteginin surdurulebilir ve olceklenebilir sekilde uygulanmasinin anahtaridir. Cevirinin otesinde kulturel uyarlama ise urunun hedef pazarda gercek anlamda benimsenmesini saglayan kritik bir adimdir.