Kurumsal Web Uygulamalarında Dil Zenginleştirme (i18n)

Bir web uygulamasına ikinci bir dil eklemek ilk bakışta birkaç JSON dosyası oluşturmak kadar kolay görünebilir. On yıllık geliştirme deneyimimde asıl sorunların çeviri metinlerinden çok locale seçimi, tarih ve para formatları, yön bilgisi, backend bildirimleri, SEO, legal içerik ve release süreçlerinde ortaya çıktığını gördüm. Kurumsal Web Uygulamalarında Dil Zenginleştirme (i18n) yaklaşımı bu nedenle yalnızca kullanıcı arayüzündeki kelimeleri çevirmek değil, ürünü farklı dil ve pazarlarda güvenilir biçimde çalışabilecek şekilde tasarlamaktır. Bu rehberde kurumsal web uygulamalarında i18n nasıl uygulanır sorusunu frontend, backend, veri, SEO, güvenlik, erişilebilirlik, test ve yönetişim katmanlarıyla birlikte ele alacağız. Amacımız, yeni bir locale eklendiğinde ekiplerin yüzlerce dosyayı elle düzeltmek zorunda kalmadığı, ölçülebilir ve sürdürülebilir bir internationalization altyapısının nasıl kurulacağını göstermektir.

Internationalization (i18n) Nedir?

Internationalization, bir yazılımın farklı dil, bölge, yazı sistemi ve kültürel formatlara sonradan büyük mimari değişiklik gerektirmeden uyarlanabilmesini sağlayan mühendislik yaklaşımıdır. Uygulamadaki metinlerin koddan ayrılması bunun yalnızca başlangıç noktasıdır. Tarih, sayı, para birimi, sıralama, çoğul kuralları ve metin yönü de aynı mimarinin parçalarıdır. Başarılı bir i18n sistemi yeni locale eklemeyi özel proje olmaktan çıkarıp kontrollü bir ürün yeteneğine dönüştürür. Kurumsal ölçekte amaç, her yeni pazarda farklı bir uygulama üretmek yerine aynı ürün mimarisinin yerel gereksinimlere uyum sağlamasıdır.

i18n Kısaltması Nereden Gelir?

i18n, İngilizcedeki internationalization kelimesinin ilk ve son harfi arasında bulunan on sekiz harften türetilen yaygın bir kısaltmadır. Benzer biçimde localization için l10n ifadesi kullanılır. Bu kısaltmalar uzun teknik kavramların dokümantasyon ve issue takibinde daha rahat kullanılmasını sağlar. Ancak ekip içinde terimlerin anlamı açık değilse kısa ifadeler yanlış sorumluluk paylaşımına yol açabilir. Bu nedenle i18n'in altyapı, l10n'in ise belirli locale için uyarlama süreci olduğunu başlangıçta netleştirmek faydalıdır.

Bir Uygulamayı Internationalized Yapmak Ne Demektir?

Bir uygulamayı internationalized yapmak, kaynak kodu tek bir dil veya bölgenin varsayımlarına bağlı olmaktan çıkarmaktır. Kullanıcıya görünen string'ler resource sistemine taşınır ve locale-aware formatter kullanılır. Layout yalnızca soldan sağa metin için tasarlanmaz, input modelleri tek bir isim veya adres biçimini zorunlu kabul etmez. Backend bildirimleri ve PDF çıktıları da aynı locale bağlamını anlayabilir hale gelir. Böylece localization ekibi yeni bir dil üzerinde çalışırken engineering ekibinin her cümle için yeni deployment mantığı geliştirmesi gerekmez.

i18n'in Temel Amaçları

i18n'in temel amacı yazılımı farklı dil ve pazar gereksinimlerine teknik olarak hazır hale getirmektir. Bu hazırlık kullanıcıya doğru metni göstermek kadar doğru tarih, sayı ve currency biçimini de kapsar. Tasarımın metin uzamasına ve farklı script yapılarına dayanıklı olması gerekir. Yeni locale eklenmesi release riskini artırmamalı ve mevcut locale'leri bozmamalıdır. İyi internationalization mimarisi ürünün küresel büyümesini tek seferlik manuel düzenlemeler yerine tekrar edilebilir süreçlerle destekler.

Dil Desteği

Dil desteği kullanıcıya görünen metinlerin seçilen dilde sunulmasını sağlar. Bu yalnızca button ve menu label'larından ibaret değildir. Error message, validation, notification, e-mail ve report gibi bütün kullanıcı temas noktaları kapsam içinde düşünülmelidir. Bir ekranın yüzde doksanının çevrilmiş olması kalan yüzde onluk hard-coded metni daha görünür hale getirir. Bu nedenle desteklenen her locale için translation coverage ölçülmeli ve eksik key'ler release sürecinde izlenmelidir.

Bölgesel Formatlar

Aynı dil kullanılsa bile tarih, sayı, para ve ölçü birimi tercihleri bölgelere göre değişebilir. Örneğin İngilizce konuşan iki pazarda tarih sırası veya currency aynı olmak zorunda değildir. Locale bu tür tercihleri modellemek için dilden daha zengin bir bağlam sağlar. Uygulama format string'lerini elle birleştirmek yerine platformun locale-aware formatter'larını kullanmalıdır. Bu yaklaşım yeni bölge eklendiğinde farklı ekranlarda ayrı ayrı format düzeltme ihtiyacını azaltır.

Kültürel Uyumluluk

Kültürel uyumluluk yalnızca sözcüklerin doğru çevrilmesinden daha geniş bir konudur. Tarih gösterimi, hitap biçimi, isim alanları, renk anlamları ve örnek içerikler kullanıcı beklentisini etkileyebilir. Bir pazarda doğal görünen form düzeni başka bir pazarda gereksiz veya hatalı varsayımlar taşıyabilir. Localization review bu tür farkları ürün bağlamında değerlendirmelidir. Engineering ekibi de kültürel değişikliklerin uygulanabilmesi için component ve content modelini yeterince esnek tasarlamalıdır.

Yeni Pazarlara Ölçeklenebilirlik

Yeni bir pazara açılmak her seferinde ayrı kod dalı oluşturmayı gerektiriyorsa i18n altyapısı ölçeklenebilir değildir. Locale listesi, translation kaynakları ve market kuralları merkezi biçimde yönetilmelidir. Yeni locale aynı pipeline üzerinden TMS, QA, SEO ve deployment adımlarına girebilmelidir. Pazara özgü legal veya billing davranışı translation dosyasına gizlenmemelidir. Ölçeklenebilirlik, dil ile gerçek business market farklılıklarını doğru katmanlarda yönetebilmekle başlar.

i18n, l10n, Globalization ve Translation Arasındaki Fark

Bu dört terim aynı proje içinde sık kullanılsa da farklı sorumlulukları ifade eder. Internationalization yazılımı farklı locale'lere hazır hale getiren teknik altyapıdır. Localization belirli bir locale için ürünün uyarlanmasını, translation ise metnin bir dilden diğerine aktarılmasını ifade eder. Globalization ürün, operasyon, pazarlama ve teknik süreçlerin birden fazla pazarda çalışmasını kapsayan daha geniş organizasyon yaklaşımıdır. Kurumsal ekiplerde bu ayrım yapılmadığında çeviri problemi sanılan birçok mimari konu localization ekibine gereksiz biçimde yüklenir.

Internationalization

Internationalization ürünün farklı locale'leri destekleyebilmesi için gerekli teknik soyutlamaları kurar. Translation key, formatter, locale resolver ve RTL desteği bu katmana örnektir. Engineering ekibi yeni dil gelmeden önce bile altyapıyı hazırlayabilir. Internationalization başarılıysa yeni locale çoğunlukla resource ve konfigürasyon eklenerek devreye alınabilir. Bu nedenle i18n'i bir content operasyonu değil software architecture sorumluluğu olarak görmek gerekir.

Localization

Localization, internationalized ürünün belirli bir dil, bölge veya pazara uyarlanmasıdır. Çeviri, tarih formatı, yerel legal metin ve görsel uyarlamalar bu sürecin parçaları olabilir. Aynı dil için iki farklı pazarda farklı localization kararları gerekebilir. Localization ekibi terminoloji, kültürel uygunluk ve linguistic QA üzerinde yoğunlaşır. Teknik altyapı yetersizse localization ekibi doğru çeviriyi hazırlasa bile ürün bunu doğru biçimde gösteremeyebilir.

Translation

Translation kaynak metnin hedef dilde anlamını koruyarak yeniden ifade edilmesidir. Bu iş i18n sürecinin önemli fakat sınırlı bir bölümüdür. Translator doğru metni üretse bile placeholder, plural veya UI context bilgisi yetersizse sonuç işlevsel olmayabilir. Translation memory ve glossary tutarlılığı artırabilir. Uygulamanın routing veya currency davranışı ise translation görevi değildir.

Globalization

Globalization ürünün farklı ülkelerde teknik, ticari ve operasyonel olarak çalışabilmesini hedefleyen geniş bir stratejidir. Pricing, payment, support, legal uyum ve localization aynı program içinde yer alabilir. i18n bu programın yazılım mimarisi tarafındaki temel yeteneklerinden biridir. Globalization kararları product ve business ekiplerini de doğrudan etkiler. Bu nedenle locale roadmap yalnızca frontend ekibinin teknik backlog'u olarak ele alınmamalıdır.

Hangisi Engineering Sorumluluğudur?

Engineering temel olarak internationalization altyapısının güvenilir çalışmasından sorumludur. Translation key sistemi, locale resolution, formatter, routing, backend propagation ve test otomasyonu bu alana girer. Engineering ayrıca translator'ın placeholder veya markup nedeniyle hata yapmasını engelleyen güvenli araçları sağlamalıdır. Çeviri metninin dil kalitesini belirlemek developer'ın ana sorumluluğu değildir. Buna rağmen ekipler context ve UI kısıtlarını localization tarafına aktarmak için yakın çalışmalıdır.

Hangisi Localization Ekibinin Sorumluluğudur?

Localization ekibi hedef locale'deki dil, terminoloji ve kültürel uygunluk kalitesini yönetir. Translator assignment, review, glossary ve linguistic QA bu sorumluluğun parçalarıdır. Ekip ayrıca kaynak mesajın yeterli context içermediğini engineering tarafına bildirebilmelidir. Legal veya brand-critical metinlerde ilgili uzmanlardan onay akışı yürütülebilir. İyi modelde localization ekibi source code düzenlemek zorunda kalmadan onaylı içerikleri yayın sürecine aktarabilir.

Kurumsal Web Uygulamalarında i18n Neden Zordur?

Kurumsal ürünlerde i18n zorluğu tek bir ekranın çevrilmesinden değil sistemin ölçeğinden doğar. Binlerce string, birden fazla frontend, backend notification'ları ve farklı tenant gereksinimleri aynı locale modeline bağlanabilir. Release sıklığı arttıkça çevirinin feature koduyla senkron kalması da zorlaşır. Legal içerik veya ödeme mesajları normal UI string'inden daha sıkı onay gerektirir. Bu nedenle Kurumsal Web Uygulamalarında Dil Zenginleştirme (i18n) baştan ownership, versioning ve kalite kontrolü olan bir platform yeteneği şeklinde tasarlanmalıdır.

Binlerce UI String

Büyük ürünlerde button label'larından gelişmiş rapor açıklamalarına kadar binlerce kullanıcı metni bulunabilir. Bu string'ler plansız biçimde tek dosyada tutulduğunda ownership ve review zorlaşır. Feature veya domain namespace yaklaşımı kaynakların daha yönetilebilir bölümlere ayrılmasını sağlar. Kullanılmayan key'lerin otomatik bulunması translation maliyetini azaltır. Translation coverage yalnızca toplam sayı değil kritik user journey bazında da ölçülmelidir.

Hızlı Release Döngüsü

Haftada veya günde birden fazla release yapan ekiplerde klasik toplu çeviri süreci yeterince hızlı olmayabilir. Feature code hazır olduğunda hedef locale çevirilerinin henüz review edilmemiş olması sık karşılaşılan durumdur. Continuous localization yeni key'leri otomatik olarak TMS'e göndererek gecikmeyi azaltır. Feature flag locale bazında rollout kontrolü sağlayabilir. Böylece localization süreci development hızını durdurmadan kalite kapılarını koruyabilir.

Backend Tarafından Üretilen İçerikler

E-mail, SMS, PDF ve scheduled report gibi içerikler çoğu zaman frontend dışında üretilir. Yalnızca browser tarafında translation library kullanmak bu çıktıları çözmez. Backend kullanıcının locale ve time zone bilgisini güvenli biçimde resolve etmelidir. Mesaj template'leri frontend terminolojisiyle aynı glossary kurallarını izlemelidir. Aksi halde kullanıcı uygulamayı Türkçe kullanırken e-mail içeriğini başka dilde alabilir.

Birden Fazla Frontend

Kurumsal ürünün web, admin paneli, embedded portal ve mobil web gibi farklı frontend yüzeyleri bulunabilir. Her uygulama kendi locale listesi ve key standardını geliştirirse zaman içinde davranışlar ayrışır. Shared taxonomy ve ortak translation platform bu farkı azaltır. Component library locale-aware formatter ve accessibility davranışlarını da paylaşabilir. Buna rağmen her frontend'in gerçekten ihtiyaç duyduğu namespace'leri ayrı yüklemesi performans açısından daha uygundur.

Birden Fazla Microservice

Microservice mimarisinde locale bilgisinin hangi servise kadar taşınacağı açıkça belirlenmelidir. Her servis presentation concern taşımak zorunda değildir. Billing calculation gibi domain servisleri language'den bağımsız machine-readable sonuç üretebilir. Kullanıcıya görünen notification service ise locale bilgisine ihtiyaç duyabilir. Bu ayrım locale propagation'ın gereksiz biçimde bütün request graph'ına yayılmasını önler.

Enterprise Tenant Özelleştirmeleri

Bazı kurumsal müşteriler ürün içindeki belirli terimlerin kendi şirket sözlüğüne göre değiştirilmesini isteyebilir. Tenant override sistemi base translation üzerine kontrollü katman ekleyebilir. Override precedence ve stale translation politikası baştan tanımlanmalıdır. Base string değiştiğinde eski müşteri override'ının hâlâ doğru olup olmadığı otomatik olarak bilinemez. Bu nedenle version, diff ve review-required durumu tenant localization mimarisinin önemli parçalarıdır.

Legal ve Compliance Metinleri

Legal metinler normal UI translation'ı gibi otomatik fallback ile yönetilmemelidir. Belirli market için onaylanmış metnin başka locale'den sessizce gösterilmesi hukuki risk oluşturabilir. Version, effective date ve approval bilgisi içerikle birlikte tutulmalıdır. Değişiklik audit trail üzerinden izlenebilir olmalıdır. Engineering fallback mekanizmasının legal content türlerinde kontrollü olarak durdurulabilmesini desteklemelidir.

i18n Neden Sadece Çeviri Problemi Değildir?

Çeviri yalnızca kullanıcıya gösterilen cümlenin dilini değiştirir. Oysa internationalization URL'nin nasıl oluşturulduğunu, tarihin nasıl gösterildiğini ve içeriğin hangi yönde aktığını da belirleyebilir. Backend data modelinden SEO alternate link'lerine kadar birçok sistem locale bilgisini kullanır. CI eksik translation veya bozuk ICU mesajını production'a çıkmadan yakalamalıdır. Bu nedenle çok dilli web uygulaması için internationalization altyapısı nasıl kurulur sorusunun cevabı translation dosyasından değil bütün ürün mimarisinden başlar.

Routing

Routing locale'nin URL'de açık biçimde temsil edilmesini sağlayabilir. /tr/ ve /de/ gibi path'ler kullanıcı, server ve arama motoru için anlaşılır locale ayrımı sunar. Language switch mümkünse aynı içeriğin diğer locale URL'sine geçmelidir. Route üretimi hard-coded string yerine locale-aware helper üzerinden yapılabilir. SSR veya direct navigation sırasında server da aynı route taxonomy'sini anlamalıdır.

Formatting

Tarih, sayı, yüzde ve para birimi yalnızca string translation ile doğru hale gelmez. Platformun Intl API'leri locale verisine göre uygun format üretebilir. Currency ile locale ayrı parametreler olarak düşünülmelidir. User time zone da dil tercihinden bağımsızdır. Formatting helper'ları ortaklaştırmak ekranların birbirinden farklı kurallar uygulamasını engeller.

Layout

Metin uzunluğu ve yazı yönü layout üzerinde doğrudan etkilidir. Almanca gibi diller bazı kısa İngilizce label'ları ciddi biçimde uzatabilir. RTL script'ler inline yönün ters akmasını gerektirir. Sabit width ve left/right bağımlı CSS bu değişikliklerde kolayca bozulur. Design system flexible layout ve logical CSS properties ile bu riskleri başlangıçta azaltmalıdır.

Database

Business content birden fazla dilde saklanacaksa database modeli locale bilgisini taşımalıdır. UI translation dosyası ile CMS veya product catalog çevirileri birbirine karıştırılmamalıdır. Translation table veya JSON localized field seçenekleri sorgu ve ownership ihtiyaçlarına göre seçilebilir. Unique constraint locale ile birlikte düşünülmelidir. Search ve fallback query'leri performans açısından ölçülmelidir.

API

API contract mümkün olduğunca machine-readable ve locale'den bağımsız kalmalıdır. Error code stabil bir identifier olarak döndürülürken kullanıcı mesajı presentation katmanında çevrilebilir. Bazı notification veya document API'leri explicit locale parametresine ihtiyaç duyabilir. Locale header kullanılıyorsa anlamı dokümante edilmelidir. API consumer'ın locale bilgisine gerçekten ihtiyaç duyup duymadığı her endpoint için sorgulanmalıdır.

SEO

Public multilingual sayfalar ayrı ve crawl edilebilir URL'lere ihtiyaç duyar. hreflang karşılıklı locale ilişkisini arama motorlarına bildirmeye yardımcı olur. Localized title, description ve structured data aynı içerikle uyumlu olmalıdır. Otomatik dil redirect'i crawler'ın diğer varyantları görmesini engellememelidir. SEO locale architecture'ın sonradan eklenen bir metadata işi değil URL modelinin doğal sonucudur.

Accessibility

HTML lang değeri screen reader'ın doğru telaffuz motorunu seçmesine yardımcı olur. Sayfa içinde başka dilde bölüm varsa inline lang kullanılabilir. RTL direction ve focus behavior da accessibility deneyimini etkiler. ARIA label ve form error metinleri translation kapsamına dahil edilmelidir. Yalnızca ana locale'de accessibility testi yapmak diğer dillerdeki taşma ve telaffuz problemlerini görünmez bırakır.

CI/CD

Translation key değişiklikleri normal source code değişiklikleri kadar otomatik kontrol edilmelidir. CI bozuk ICU syntax, eksik placeholder veya bilinmeyen key bulabilir. Translation artifact'ları staging ve production arasında versionlanabilir. Rollback mekanizması yalnızca application bundle'ı değil kullanılan translation version'ını da geri alabilmelidir. Continuous localization böylece release pipeline'ın ayrı ve izlenebilir bir kolu haline gelir.

Governance

Locale desteği yalnızca teknik configuration listesi değildir. Hangi locale'in production SLA aldığı, translation'ın kim tarafından onaylandığı ve eski key'in ne zaman silindiği yazılı politika gerektirir. Legal ve tenant içerikleri için daha güçlü kurallar tanımlanabilir. Yeni dil açılması product, support ve localization capacity değerlendirmesiyle yapılmalıdır. Governance bulunmadığında teknik olarak desteklenen locale kullanıcı açısından eksik bir ürün deneyimine dönüşebilir.

Language ile Locale Arasındaki Fark

Language yalnızca konuşulan veya yazılan dili ifade ederken locale daha geniş bölgesel ve kültürel tercih kümesini temsil eder. Türkçe bir language'dir, tr-TR ise Türkiye bağlamındaki Türkçeyi belirtir. Aynı language birden fazla region veya script ile kullanılabilir. Locale formatter, market ve content kararlarında daha kesin sinyal sağlayabilir. Buna rağmen ihtiyaç yoksa gereksiz region eklemek locale listesini gereksiz büyütür.

Language

Language tag'in temel kısmı kullanıcıya sunulan doğal dili tanımlar. tr, en ve de buna basit örneklerdir. Dil bilgisi tek başına currency veya time zone belirlemez. Aynı dili konuşan kullanıcılar farklı ülkelerde bulunabilir. Application yalnızca gerçekten dil seviyesinde değişen içerik için language bilgisini kullanmalıdır.

Region

Region subtag belirli ülke veya bölge kullanımını ayırt etmek için kullanılabilir. İngilizcenin ABD ve Birleşik Krallık varyantlarında yazım ve format tercihleri değişebilir. Region aynı zamanda market içeriğiyle ilişkilendirilebilir fakat doğrudan currency eşitliği olarak kabul edilmemelidir. Kullanıcının locale region'ı ile billing country farklı olabilir. Bu nedenle region sinyali her business kararında otomatik kaynak olarak kullanılmamalıdır.

Script

Script subtag bir dilin hangi yazı sistemiyle ifade edildiğini gösterir. Çince için Simplified ve Traditional ayrımı script bilgisiyle ifade edilebilir. Bazı diller birden fazla script ile yazılabilir. Script seçimi font, direction ve content kaynağını etkileyebilir. Locale modelinde script'i region ile karıştırmak yanlış fallback ve rendering kararlarına yol açabilir.

Locale

Locale dil ve gerekli olduğunda script, region veya diğer tercihleri bir araya getiren identifier olarak kullanılabilir. Application locale'yi translation resource seçimi ve formatter için ortak bağlam yapabilir. Locale ile market aynı kavram değildir. Örneğin aynı locale birden fazla satış pazarında kullanılabilir. Domain modelde bu alanların ayrı tutulması ileride pricing veya legal farklılıkları eklemeyi kolaylaştırır.

tr ve tr-TR

tr Türkçeyi herhangi bir belirli region belirtmeden ifade eder. tr-TR ise Türkiye bağlamındaki Türkçe kullanımını daha spesifik hale getirir. Uygulamanız yalnızca genel Türkçe çeviri sunuyorsa tr yeterli olabilir. Türkiye'ye özel legal, format veya market content varsa region seviyesinde ayrım anlamlı hale gelebilir. Locale listesini business gereksinimi olmadan gereksiz spesifik yapmak translation operasyonunu büyütür.

en-US ve en-GB

en-US ve en-GB aynı language'i farklı region bağlamlarında ifade eder. Yazım, tarih gösterimi ve bazı terimler değişebilir. İki locale ayrı translation set gerektiriyor mu sorusu product içeriğine göre verilmelidir. Sadece format farklıysa translation'ı paylaşarak formatter locale'sini ayırmak mümkün olabilir. Legal veya market copy farklıysa ayrı resource katmanı daha anlaşılır sonuç sağlar.

zh-Hans ve zh-Hant

zh-Hans Simplified Chinese script'ini, zh-Hant ise Traditional Chinese script'ini belirtmek için kullanılabilir. Bu ayrım yalnızca region üzerinden ifade edilmek zorunda değildir. Script font seçimi ve içerik varyantı üzerinde doğrudan etkilidir. W3C de uygun durumlarda bu script tag'lerinin kullanılmasını önerir. Locale resolver script bilgisini kaybetmeden fallback yapabilmelidir.

BCP 47 Language Tag Nedir?

BCP 47 web ve internet standartlarında dil etiketlerinin nasıl oluşturulacağını tanımlayan temel sistemdir. Language tag birincil dil subtag'iyle başlar ve gerektiğinde script, region, variant veya extension bölümleri içerebilir. Kurumsal uygulama kendi locale kod formatını uydurmak yerine bu standardı temel almalıdır. Böylece browser, formatter, HTML lang ve dış sistemlerle uyumluluk artar. Locale validation için IANA Language Subtag Registry ile uyumlu bir yaklaşım kullanmak daha güvenlidir.

Language Subtag

Language subtag tag'in ilk ve temel parçasıdır. Genellikle tr, en veya de gibi değerlerle karşılaşılır. Bu değerler keyfi ürün kodları değildir. Doğru subtag registry üzerinden seçilmelidir. Internal olarak turkish gibi özel değer kullanmak platform entegrasyonlarında gereksiz mapping ihtiyacı yaratır.

Script Subtag

Script subtag kullanılan yazı sistemini belirtir ve gerektiğinde language'den sonra gelir. Latn, Cyrl, Hans ve Hant gibi değerlerle karşılaşılabilir. Script yalnızca görsel font farkı değildir, locale content varyantını da belirleyebilir. Uygulama fallback sırasında script bilgisini yanlışlıkla kaybetmemelidir. Özellikle birden fazla script kullanılan dillerde explicit model büyük fayda sağlar.

Region Subtag

Region subtag dilin belirli coğrafi kullanımını işaret eder. US, GB veya TR gibi değerler locale'in daha spesifik olmasını sağlar. Region yalnızca gerçekten ürün davranışında gerekli ayrımı oluşturuyorsa kullanılmalıdır. Bir ülkenin tek bir dil konuştuğunu varsaymak doğru değildir. Benzer şekilde locale region'ını kullanıcının fiziksel konumu olarak yorumlamak da risklidir.

Variant

Variant subtag belirli dil kullanımının daha özel biçimini tanımlayabilir. Her ürünün variant seviyesinde locale kullanmasına ihtiyaç yoktur. Gereksiz variant desteği translation fallback zincirini büyütebilir. Bir variant gerçek content veya format farkı yaratıyorsa standard registry değerleri kullanılmalıdır. Internal business segment'leri BCP 47 variant gibi davranacak özel kodlara dönüştürülmemelidir.

Locale Identifier'ları Elle Uydurmamak

tr_TR, TR-tr veya ekip içinde rastgele belirlenen kodlar uzun vadede entegrasyon problemi yaratabilir. Browser ve JavaScript Intl API'leri standard locale tag'leriyle daha uyumlu çalışır. HTML lang ve SEO annotation'ları da standard değer bekler. Locale allowlist uygulamaya özgü olabilir fakat değerlerin biçimi standarda dayanmalıdır. Bu karar küçük görünse de bütün i18n veri akışını sadeleştirir.

Desteklenecek Locale'ler Nasıl Seçilmeli?

Her mümkün locale'i desteklemek gerçekçi bir ürün hedefi değildir. Translation, support, QA ve legal operasyonlarının her biri yeni locale ile büyür. Locale roadmap user demand, revenue ve contract gereksinimi gibi ölçülebilir sinyallerle belirlenmelidir. Destek seviyesi Tier modeliyle farklılaştırılabilir. Böylece deneysel bir locale ile tam kurumsal SLA verilen locale aynı beklenti altında yönetilmez.

User Demand

Kullanıcıların hangi dilde ürün talep ettiği locale önceliği için güçlü sinyaldir. Support ticket, sales request ve product analytics birlikte değerlendirilebilir. Browser language dağılımı yalnızca tahmin sağlar ve doğrudan talep anlamına gelmez. Kullanıcıların manuel locale switch davranışı daha anlamlı veri sağlayabilir. Talep yalnızca kullanıcı sayısıyla değil kritik müşteri segmentleriyle de ölçülmelidir.

Revenue Opportunity

Yeni locale potansiyel gelir veya conversion artışı sağlayabilir. Ancak translation maliyetiyle birlikte support ve market operasyonu da hesaba katılmalıdır. Sadece web arayüzünü çevirmek tam market readiness anlamına gelmez. Pricing, payment ve legal gereksinimleri ayrıca incelenmelidir. Locale business case'i ürünün gerçek satın alma yolculuğuna göre hazırlanmalıdır.

Enterprise Contract

Büyük müşteri sözleşmeleri belirli locale desteğini zorunlu hale getirebilir. Böyle durumda scope yalnızca UI translation olarak bırakılmamalıdır. E-mail, PDF, support ve legal belgelerin de sözleşme kapsamına girip girmediği netleştirilmelidir. SLA translation freshness veya support süresi içerebilir. Engineering bu gereksinimleri feature roadmap içinde görünür hale getirmelidir.

Regulatory Requirement

Bazı pazarlarda belirli kullanıcı bilgilerinin yerel dilde sunulması gerekebilir. Bu tür gereksinimler uzman legal değerlendirmesiyle netleştirilmelidir. Engineering approved content'in doğru locale ve version ile gösterilmesini garanti eden sistemi kurar. Otomatik fallback regulatory içerikte kapatılabilir. Requirement locale roadmap içinde yüksek öncelikli kalite kapısı olarak ele alınmalıdır.

Support Capacity

Ürün bir dili desteklediğini söylediğinde kullanıcı support kanalında da benzer beklenti oluşturabilir. Localization açılırken customer success ve support kapasitesi değerlendirilmelidir. Otomatik translation support kalitesinin tamamını çözmez. Help center ve onboarding materyallerinin coverage durumu da önemlidir. Teknik olarak açılabilen locale operasyonel olarak hazır değilse staged rollout daha güvenli olur.

Localization Cost

Localization maliyeti yalnızca kelime başına translation ücretinden oluşmaz. Review, linguistic QA, screenshot testleri ve sürekli yeni string akışı maliyet yaratır. Çok fazla benzer region locale'i gereksiz content duplication oluşturabilir. Shared base translation ve market override modeli bu maliyeti azaltabilir. Locale seçiminde uzun vadeli release hacmi de hesaba katılmalıdır.

Locale Tier Modeli

Tier modeli desteklenen locale'lere farklı kalite ve operasyon seviyeleri tanımlar. Tier 1 locale tam translation coverage ve düzenli linguistic QA alabilir. Tier 2 locale daha düşük release SLA ile yönetilebilir. Experimental locale sınırlı kullanıcı grubuna açılabilir. Bu sınıflandırma product promise ile ekip kapasitesinin uyumlu kalmasını sağlar.

Tier 1

Tier 1 locale işletme açısından kritik ve tam destek verilen dil veya marketleri kapsar. Translation coverage production release öncesinde yüksek eşik altında tutulur. Legal ve SEO kontrolleri zorunlu olabilir. Linguistic QA düzenli çalıştırılır. Production incident ve support metriği locale bazında ayrıca izlenir.

Tier 2

Tier 2 locale önemli fakat Tier 1 kadar yüksek operasyon taahhüdü taşımayan alanları kapsayabilir. Bazı düşük öncelikli feature'larda translation gecikmesi kabul edilebilir. Fallback politikası kullanıcıya zarar vermeyecek şekilde belirlenir. Linguistic QA daha seyrek uygulanabilir. Yine de security veya legal içerikte kalite standardı düşürülmemelidir.

Experimental

Experimental locale gerçek kullanıcı talebini ölçmek için sınırlı rollout ile açılabilir. Kullanıcıya desteğin kapsamı açıkça belirtilmelidir. Missing translation telemetry yoğun biçimde izlenir. Feature flag ile kolayca kapatılabilir olmalıdır. Deney başarılı olursa Tier 2 veya Tier 1 seviyesine geçiş için net kriterler kullanılmalıdır.

Language ve Market Ayrı mı Yönetilmeli?

Evet, language ile market çoğu kurumsal üründe ayrı kavramlar olarak modellenmelidir. Aynı dil birden fazla ülkede farklı legal, pricing veya tax kurallarıyla kullanılabilir. Benzer şekilde tek markette birden fazla language desteklenebilir. Locale bu iki kavram arasında yararlı bağlam sağlar fakat business market modelinin yerine geçmemelidir. Bu ayrım özellikle commerce ve enterprise ürünlerde yanlış currency veya legal metin gösterme riskini azaltır.

İspanyolca Tek Locale Yeterli mi?

Bazı ürünlerde genel es translation bütün kullanıcılar için yeterli olabilir. Başka ürünlerde terminoloji ve market copy bölgelere göre farklılaşabilir. Karar, dilbilimsel farklılığın yanı sıra business gereksinimine göre verilmelidir. Her ülke için ayrı locale oluşturmak gereksiz operasyon yükü getirebilir. Shared Spanish base ve seçili market override'ları daha dengeli bir model sağlayabilir.

es-ES ve es-MX

es-ES ve es-MX aynı language'i farklı region bağlamlarında ifade eder. Bazı kelimeler, tarih ve number formatları farklılaşabilir. Ürün bu farkları kullanıcı deneyiminde gerçekten gösteriyorsa iki locale anlamlıdır. Translation memory ortak segmentlerden faydalanabilir. Market-specific legal content ise base Spanish translation'dan ayrı yönetilmelidir.

Dil Aynı Olsa da Legal Metinlerin Değişmesi

Legal metinlerin dili aynı olsa bile geçerli ülke veya sözleşme modeline göre içerik değişebilir. Bu nedenle legal document seçimini sadece language key'e bağlamak doğru değildir. Market, version ve effective date bilgileri ayrıca kullanılmalıdır. Kullanıcıya yanlış market metni gösterilmemelidir. Legal content resolution normal UI fallback zincirinden ayrı tutulabilir.

Currency ve Tax Farkları

Currency kullanıcı dilinden otomatik çıkarılmamalıdır. Aynı language kullanıcıları farklı para birimleriyle işlem yapabilir. Billing currency sözleşme veya hesap ayarından gelebilir. Tax modeli de market ve business entity bilgisine bağlıdır. Locale yalnızca currency'nin nasıl gösterileceği konusunda format bağlamı sağlayabilir.

Market-Specific Content

Kampanya, support telefonu veya teslimat bilgisi market'e özel olabilir. Bu içerikleri language translation dosyasına gömmek reuse ve ownership sorunları yaratır. CMS veya market configuration daha uygun kaynak olabilir. Locale yalnızca doğru dil varyantını seçmeye yardım eder. Market ve language katmanları composition sırasında bir araya getirilebilir.

Kurumsal i18n Referans Mimarisi

Kurumsal i18n referans mimarisi uygulama kodu, translation key, locale resolver, localization library ve translation kaynaklarını birbirinden ayırır. TMS içerik operasyonunu, CDN runtime dağıtımı ve CI/CD kalite doğrulamasını yönetebilir. QA ile monitoring production davranışını görünür hale getirir. Kurumsal Web Uygulamalarında Dil Zenginleştirme (i18n) böyle katmanlı kurulduğunda framework değişse bile temel sözleşmeler korunabilir. React Next.js ve Vue projelerinde i18n çözümleri karşılaştırması yapılırken de library API'lerinden önce bu sorumlulukların hangi katmanda çözüldüğüne bakmak daha doğru sonuç verir.

Application Code

Application code kullanıcıya gösterilecek metni doğrudan hard-code etmek yerine translation API çağrısı yapar. Locale seçimi component içinde tekrar tekrar hesaplanmamalıdır. Formatter ve route helper gibi ortak servisler kullanılır. Business logic mümkün olduğunca language'den bağımsız tutulur. Böylece localization değişiklikleri domain hesaplamalarını etkilemez.

Translation Keys

Translation key kullanıcı metnini source code ile resource arasında bağlayan stabil identifier'dır. Semantic ve feature-scoped key'ler context'i daha iyi taşır. Key rename normal refactoring gibi impact analizi gerektirir. Key'in display text ile aynı olması copy değişikliklerini teknik breaking change'e dönüştürebilir. Bu nedenle key naming standardı proje başında belirlenmelidir.

Locale Resolver

Locale resolver URL, user preference ve tenant default gibi sinyalleri belirli öncelik sırasıyla değerlendirir. Sonuç yalnızca desteklenen locale listesi içinde olmalıdır. Fallback deterministic olmalıdır. Kullanıcının explicit tercihi browser tahmininden daha güçlü kabul edilir. Resolver hem server hem client tarafında aynı sonucu üretmelidir.

Translation Resources

Translation resources locale ve namespace bazlı mesajları içerir. Dosya, API veya CDN üzerinden sağlanabilir. Resource version application release'iyle uyumlu tutulmalıdır. Eksik namespace yüklemesi kullanıcıya raw key göstermemelidir. Cache stratejisi locale ve version değerlerini dikkate almalıdır.

Localization Library

Localization library message lookup, placeholder ve plural gibi runtime işlerini kolaylaştırır. Framework entegrasyonu seçimde önemli olsa da standard ICU davranışına yakınlık daha uzun ömürlü değer sağlayabilir. Library bütün locale bilgisini component'lere global mutable state olarak yaymamalıdır. SSR kullanılıyorsa request isolation desteklenmelidir. Test ortamında deterministic locale seçilebilmesi de önemlidir.

Translation Management System

TMS developer key'lerini translator workflow'una bağlayan operasyon katmanıdır. Translation memory, glossary, review ve versioning özellikleri sunabilir. Developer'ın spreadsheet gönderip geri alma sürecini ortadan kaldırır. API veya CLI entegrasyonu continuous localization sağlar. Security açısından access control ve audit log gereksinimleri değerlendirilmelidir.

Translation CDN

Translation CDN approved resource'ları kullanıcıya yakın noktadan sunabilir. Runtime update modelinde uygulama yeniden deploy edilmeden içerik değişebilir. Cache key locale, namespace ve translation version bilgilerini içerebilir. Invalidation kontrolsüz yapılırsa eski ve yeni translation'lar karışabilir. Client network hatasında güvenli fallback veya bundled critical namespace bulunmalıdır.

CI/CD Pipeline

CI translation key ve ICU syntax doğrulamasını source code testleriyle birlikte çalıştırabilir. TMS sync işlemi pipeline'ın ayrı adımı olabilir. Approved translation staging ortamına promotion ile alınır. Production publish version tag üzerinden izlenebilir. Rollback uygulama ve translation artifact'ını uyumlu biçimde geri çevirmelidir.

QA ve Monitoring

QA yalnızca çevirinin dil kalitesini değil functional ve visual davranışı da kapsar. Pseudo-localization hard-coded string ve overflow sorunlarını erken gösterir. Production monitoring missing key ve fallback oranını izler. Locale bazlı conversion veya support ticket metriği kullanıcı etkisini ölçer. Bu veriler bir sonraki localization yatırımını yönlendirebilir.

React tarafında i18n library seçimi uygulamanın render ve state modeline uyum üzerinden yapılırken Next.js App Router locale segmentini server rendering ve routing ile daha yakın ilişkilendirebilir. Vue projelerinde Vue I18n component ve Composition API modeliyle localization katmanı sunar. Framework seçimi translation key, BCP 47, ICU, fallback ve SEO gibi temel prensipleri değiştirmez. Bu nedenle kurumsal mimaride framework-specific adapter ile domain-level locale modelini ayrı tutmak daha sağlıklıdır. Böyle bir yapı teknoloji değiştiğinde translation asset'lerinin ve governance sürecinin korunmasını kolaylaştırır.

Kullanıcıya Gösterilen Metinleri Koddan Ayırmak

i18n altyapısının ilk somut adımlarından biri kullanıcıya gösterilen metinleri source code içinden çıkarmaktır. Hard-coded string developer'ın hızlı yazmasını kolaylaştırır fakat yeni locale geldiğinde bütün codebase'in taranmasını gerektirir. Resource bundle translation operasyonuna açık bir yüzey oluşturur. UI logic yalnızca hangi mesajın gerektiğine karar verir. Mesajın dili ve gerçek metni locale resource tarafından belirlenir.

Hard-Coded String Problemi

Hard-coded string translation coverage tarafından kolayca izlenemez. Translator source code'a erişmeden metni göremez. Aynı metin farklı ekranlarda farklı context gerektirebilir. Refactoring sırasında benzer string'lerin gerçekten aynı anlamı taşıdığı yanlış varsayılabilir. Lint veya pseudo-localization bu tür metinleri yakalamaya yardımcı olabilir.

Resource Bundle

Resource bundle locale'e ait translation mesajlarını düzenli biçimde saklar. Bundle namespace veya feature bazında bölünebilir. Her bundle bütün locale'ler için aynı key şemasını takip edebilir. Runtime yalnızca gerekli bundle'ları yükleyebilir. Resource formatı translator tarafından doğrudan düzenlenmek zorunda değildir.

Translation Key

Translation key source code'da mesajın semantic kimliğini temsil eder. Key stabil kaldığında metin defalarca değişebilir. Aynı English cümle iki farklı context'te kullanılıyorsa ayrı key gerekebilir. Key'in description metadata'sı translator'a ek bilgi verir. Unknown key production'a çıkmadan CI tarafından yakalanmalıdır.

UI Logic ile Content'i Ayırmak

UI logic kullanıcı state'ine göre hangi mesajın gösterileceğine karar verebilir. Cümlenin kelime sırasını JavaScript condition'larıyla üretmemelidir. Content resource tam cümle veya ICU message olarak tutulabilir. Bu ayrım translator'ın hedef dilde doğal sentence structure kurmasını sağlar. Component yalnızca placeholder value sağlayarak metnin grammar yapısına karışmaz.

İlk Dil Tek Olsa Bile Key Kullanmak

Ürün bugün yalnızca Türkçe veya İngilizce olsa bile ileride internationalization planı varsa key kullanmak migration maliyetini azaltabilir. Her küçük prototype için bu investment şart değildir. Uzun ömürlü kurumsal uygulamalarda shared component'lerden başlamak genellikle avantajlıdır. Key sistemi kaynak dilin değiştirilmesini de kolaylaştırır. Bunun için naming ve extraction sürecinin başlangıçtan standardize edilmesi gerekir.

Translation Key Nasıl Tasarlanmalı?

Translation key'in amacı yalnızca benzersiz olmak değildir, mesajın kullanım context'ini de anlaşılır hale getirmektir. Semantic ve feature-scoped naming büyük codebase'de ownership sağlar. Çok generic button.ok gibi key'ler farklı anlamları yanlışlıkla birleştirebilir. Component bazlı key bazı durumlarda faydalı olsa da metin domain'e aitse component adıyla aşırı bağlanmamalıdır. Key tasarımı source code refactoring ve localization review ihtiyaçlarını birlikte düşünmelidir.

Semantic Key

Semantic key mesajın ne işe yaradığını anlatır. billing.invoice.download kullanımı button.text.17 gibi anlamsız identifier'dan daha açıklayıcıdır. Translator context'i key'den kısmen anlayabilir. Developer code search ile related messages'ı bulabilir. Semantic naming copy değişse bile key'in stabil kalmasını sağlar.

Feature-Scoped Key

Feature scope aynı kelimenin farklı ürün alanlarında ayrı anlam taşımasını sağlar. Authentication içindeki “continue” ile billing flow içindeki “continue” aynı translation olmak zorunda değildir. Feature prefix ownership'i görünür hale getirir. Namespace lazy loading ile de doğal eşleşebilir. Çok derin hierarchy ise key kullanımını gereksiz uzatabilir.

Domain Namespace

Domain namespace translation kaynaklarını business capability üzerinden böler. Billing, reporting ve administration gibi alanlar ayrı ownership taşıyabilir. Ekipler kendi namespace'lerinin translation quality'sini izleyebilir. Release ve lazy loading kararları da domain bazında verilebilir. Shared mesajlar yalnızca gerçekten ortaksa common namespace'e taşınmalıdır.

Component Bazlı Key

Component bazlı key yalnızca ilgili reusable component'e ait mesajlarda anlaşılır olabilir. Dialog close label veya date picker helper metni buna örnek olabilir. Domain mesajını component adına bağlamak component refactor'ını translation rename'e dönüştürebilir. Bu nedenle mesaj ownership'i doğru belirlenmelidir. Component ve domain context gerektiğinde birlikte kullanılabilir.

Key'de UI Context Belirtmek

Aynı kaynak kelime title, button veya error message olarak farklı çeviri gerektirebilir. Key context'i bu farkı yansıtabilir. Translator screenshot olmasa bile kullanım amacını daha iyi anlayabilir. Character limit veya tone bilgisi metadata ile ayrıca sağlanabilir. Context eklemek gereksiz duplicate translation'dan daha önemlidir.

Translation Key İsimlendirme Standardı

Kurumsal projede key naming kişisel tercihe bırakılamayacak kadar merkezi bir konudur. Aynı feature içinde farklı separator veya casing kullanılması tooling ve search deneyimini bozar. Standard domain, action ve state sırasını açıklar. Rename ve deprecation politikası da naming standardının parçasıdır. CI geçersiz key pattern'lerini otomatik olarak reddedebilir.

billing.invoice.download

billing.invoice.download domain, entity ve action bilgisini anlaşılır sırayla taşır. Key yalnızca görünen English metne bağlı değildir. Invoice ekranı farklı component'e taşınsa bile semantic anlam korunur. Translator billing context'ini kolayca görebilir. Benzer pattern bütün domain boyunca tutarlı biçimde uygulanabilir.

auth.login.error.invalid_credentials

Bu key authentication, login, error ve hata sebebini açıkça belirtir. Aynı invalid credential mesajı farklı UI yüzeyinde gerekirse kolay bulunabilir. Error copy değiştiğinde identifier değişmek zorunda değildir. Analytics veya monitoring key'i doğrudan user-facing error code olarak kullanmamalıdır. Translation key presentation concern olarak kalmalıdır.

Flat Key vs Hierarchical Key

Flat key kısa ve tool-friendly olabilir. Hierarchical key ownership ve grouping bilgisini daha açık taşır. Çok derin hierarchy okunabilirliği azaltabilir. JSON nested object kullanımı ile dot-separated key kullanımı ayrı teknik tercihlerdir. Ekibin extraction, TMS ve runtime library yeteneklerine göre tek convention seçmesi daha önemlidir.

English Text'i Key Olarak Kullanmanın Riski

Kaynak cümleyi doğrudan key yapmak başlangıçta kolay görünür. Copy edit yapıldığında key değiştiği için bütün locale translation history'si gereksiz etkilenebilir. Aynı English text farklı context'te farklı çeviri gerektirebilir. Uzun sentence key code readability'yi düşürür. Semantic identifier translation memory ve review sürecini daha stabil tutar.

Key Rename Politikası

Key rename normal code refactor'dan farklı olarak external translation asset'lerini de etkiler. TMS'de eski key translation memory veya review history taşıyabilir. Rename mapping veya migration script kaybı azaltır. Eski key belirli release sonrasında deprecated olarak silinebilir. CI aynı anda eski ve yeni key'in yanlış kullanımını kontrol edebilir.

Translation Namespace Mimarisi

Namespace büyük translation kataloğunu feature veya domain parçalarına ayırır. Bu ayrım ownership, lazy loading ve review süreçlerini kolaylaştırır. Her küçük component için ayrı namespace oluşturmak request ve yönetim yükü yaratabilir. Çok büyük tek common dosya ise domain sınırlarını yok eder. Namespace tasarımı application route ve team ownership yapısıyla uyumlu olmalıdır.

common

common yalnızca gerçekten birçok feature tarafından paylaşılan mesajları içermelidir. Save, cancel veya generic accessibility label bazı ürünlerde uygun olabilir. Her tekrar eden kelime common'a taşınmamalıdır. Aynı kelimenin farklı context'te çevirisi değişebilir. Common namespace büyüdükçe review ownership'i özellikle tanımlanmalıdır.

authentication

Authentication namespace login, password reset ve session mesajlarını kapsayabilir. Security copy bu alanda özel review gerektirebilir. Error ve success mesajları aynı terminology standardını izlemelidir. Public login ekranı application'ın diğer namespace'lerinden bağımsız yüklenebilir. Böylece initial bundle gereksiz translation taşımamış olur.

onboarding

Onboarding metinleri genellikle ürün value proposition ve yönlendirme copy'si içerir. Translation burada yalnızca literal doğruluk değil tone ve akış açısından da review edilmelidir. Step sayısı locale'e göre değişmemelidir fakat metin uzunluğu layout'u etkileyebilir. Screenshot context translator'a büyük fayda sağlar. Namespace onboarding feature ownership'iyle uyumlu kalmalıdır.

billing

Billing namespace invoice, payment ve subscription mesajlarını içerebilir. Currency formatting translation dosyasına hard-code edilmemelidir. Legal veya payment disclosure normal billing UI key'inden ayrı governance gerektirebilir. Terminology finance ekibiyle onaylanabilir. Bu namespace linguistic QA için yüksek öncelikli olabilir.

settings

Settings alanı kullanıcı preference ve organization configuration metinlerini içerir. Dil switcher'ın kendisi de bu namespace içinde olabilir. Locale isimleri normal translation key gibi değil standard display name API veya approved list üzerinden üretilebilir. Ayar açıklamaları text expansion açısından test edilmelidir. Tenant-specific terminology varsa override katmanı burada devreye girebilir.

reporting

Reporting namespace table header, chart label ve export metinlerini kapsar. UI translation ile exported CSV veya PDF header'ları aynı terminology kaynağından beslenebilir. Number formatting raw data value'dan ayrı tutulmalıdır. Chart library'nin locale-aware axis format desteği doğrulanmalıdır. Uzun translated header'lar table layout testlerinde ayrıca ele alınmalıdır.

admin

Admin ekranları son kullanıcı kadar görünür olmasa da production operasyonları için kritiktir. Translation coverage düşürülürse support ekipleri mixed-language deneyim yaşayabilir. Permission ve audit mesajları açık terminology gerektirir. Admin locale desteğinin tier seviyesi ürün politikasında belirtilmelidir. Internal kullanıcılar için English fallback bilinçli karar olarak kabul edilebilir.

Namespace Ownership

Her namespace'in hangi product veya engineering ekibine ait olduğu bilinmelidir. Yeni key review'u ilgili domain owner tarafından yapılabilir. Localization ekibi terminoloji sorununu doğru ekibe yönlendirebilir. Orphan namespace zamanla stale translation biriktirir. Ownership metadata migration ve cleanup süreçlerini kolaylaştırır.

Translation File Formatları

Translation resource için tek evrensel dosya formatı yoktur. JSON developer experience açısından basitken XLIFF localization tool zincirinde daha zengin metadata taşıyabilir. PO/POT uzun yıllardır birçok localization workflow'unda kullanılır. Format seçimi runtime library, TMS ve translator araçlarının birlikte çalışabilmesine göre verilmelidir. Developer formatı ile translator exchange formatının aynı olması şart değildir.

JSON

JSON frontend projelerinde kolay parse edildiği için yaygındır. Nested veya flat key modeli desteklenebilir. Comment desteğinin olmaması translator context metadata'sını ayrı yapıda tutmayı gerektirebilir. Büyük bundle'lar namespace bazında bölünebilir. JSON'u translator'a doğrudan vermek yerine TMS üzerinden yönetmek daha güvenli olabilir.

YAML

YAML insan tarafından okunabilir configuration için rahat olabilir. Comment ve daha temiz görsel yapı bazı ekipler tarafından tercih edilir. Whitespace hataları validation gerektirir. Runtime'da parse veya build conversion adımı gerekebilir. TMS desteği kullanılmadan önce kontrol edilmelidir.

PO/POT

PO ve POT formatları localization workflow'larında yaygın exchange yapılarıdır. Source message, translation ve metadata taşıyabilir. gettext tabanlı sistemlerle doğal uyum sağlar. Frontend runtime bazen build aşamasında farklı formata dönüştürür. Existing translation ecosystem bu formatı kullanıyorsa yeniden icat etmek yerine entegrasyon yapmak avantajlıdır.

XLIFF

XLIFF localization data exchange için tasarlanmış XML tabanlı bir formattır. Source, target ve metadata ilişkisini daha zengin biçimde taşıyabilir. CAT araçlarıyla entegrasyon için güçlü seçenektir. Runtime application'ın doğrudan XLIFF parse etmesi şart değildir. Build veya TMS pipeline developer formatı ile XLIFF arasında dönüşüm sağlayabilir.

ARB

ARB formatı özellikle belirli application ecosystem'lerinde localization resource olarak kullanılabilir. Mesaj yanında metadata taşıma yaklaşımı translator context'i için faydalıdır. Kullandığınız framework veya tooling ARB'yi doğal destekliyorsa tercih edilebilir. Kurum genelinde başka platformlar varsa exchange standardı ayrıca düşünülmelidir. Format kararını yalnızca dosyanın kolay okunmasına göre vermek yeterli değildir.

XML

XML köklü enterprise toolchain'lerinde translation resource veya exchange formatı olarak bulunabilir. Metadata ve schema validation açısından güçlüdür. Frontend runtime için daha ağır olabilir. Build-time conversion JSON gibi daha hafif runtime çıktısı üretebilir. Existing localization infrastructure XML kullanıyorsa bu yatırımı korumak maliyet açısından avantaj sağlayabilir.

Hangi Format Ne Zaman Kullanılmalı?

Developer ergonomisi öncelikliyse JSON basit bir seçim olabilir. Translator tooling ve metadata exchange öne çıkıyorsa XLIFF veya PO daha uygun olabilir. Cross-platform kurumsal pipeline exchange formatı ile runtime formatını ayrı tutabilir. TMS'in import ve export yetenekleri karar üzerinde önemlidir. Format migration maliyeti de uzun vadeli tool seçiminde hesaba katılmalıdır.

XLIFF Kurumsal Localization'da Neden Önemlidir?

XLIFF kaynak uygulama formatıyla localization araçları arasında standart bir değişim katmanı sağlayabilir. Kurumsal ortamda farklı vendor veya CAT tool kullanıldığında bu taşınabilirlik değerlidir. Mesajın yalnızca text'ini değil metadata ve segment bilgisini de taşıyabilir. Developer'ın JSON şemasını translator tool'una göre sürekli değiştirmesini önler. Exchange standardı localization pipeline'ın belirli bir platforma gereksiz bağımlılığını azaltabilir.

Translation Exchange

Translation exchange source mesajların TMS veya translator ortamına taşınmasını ifade eder. XLIFF bu aktarım için tanımlı bir yapı sunar. Approved target content aynı format üzerinden geri alınabilir. Conversion CI tarafından otomatik gerçekleştirilebilir. Böylece manuel spreadsheet transferi ve copy-paste hataları azalır.

CAT Tool Uyumluluğu

Computer-assisted translation araçları translation memory ve terminology workflow'unu destekler. Standard exchange formatı farklı tool'lar arasında geçişi kolaylaştırabilir. Translator source code formatını anlamak zorunda kalmaz. Placeholder ve segment sınırları daha kontrollü gösterilebilir. Tool uyumluluğu procurement öncesi küçük pilot dosyayla test edilmelidir.

Metadata

Translation kalitesi için screenshot kadar mesaj açıklaması ve placeholder bilgisi de önemlidir. XLIFF benzeri formatlar bu metadata'nın source mesajla birlikte taşınmasına yardım edebilir. Character limit veya feature bilgisi translator workspace'te gösterilebilir. Metadata'nın güncel tutulması gerekir. Stale description yanlış çeviriye hiç context vermemekten daha yanıltıcı olabilir.

Developer Formatı ile Translator Formatını Ayırmak

Developer runtime'da hızlı parse edilen JSON kullanabilirken translator XLIFF üzerinden çalışabilir. Build pipeline iki format arasındaki mapping'i yönetir. Böylece her taraf kendi işine uygun representation kullanır. Key ve placeholder identity conversion sırasında korunmalıdır. Round-trip test translation kaybını veya metadata bozulmasını önler.

String Concatenation Neden i18n Anti-Pattern'idir?

Cümleyi birden fazla translated parça ve variable ile birleştirmek kaynak dilin kelime sırasını diğer dillere zorlar. Bir dilde isim cümlenin ortasında bulunurken başka dilde başa veya sona taşınabilir. Plural ve gender gibi grammar kuralları parçalı mesajlarda daha zor yönetilir. Translator bütün cümleyi göremediği için doğru ifade kurmakta zorlanır. Tam mesajı tek translation unit olarak vermek daha güvenli ve doğal localization sağlar.

Kelime Sırasının Diller Arasında Değişmesi

İngilizce cümle sırası Türkçe veya Japonca ile aynı değildir. Code içinde prefix + name + suffix modeli target language'i kaynak grammar'a bağlar. Translator yalnızca parçaları değiştirerek her zaman doğal cümle oluşturamaz. Placeholder tam mesaj içinde serbest konumlandırılmalıdır. Bu nedenle interpolation message pattern içinde yapılmalıdır.

Pluralization

count === 1 üzerinden iki string seçmek bütün diller için yeterli değildir. Bazı diller birden fazla plural category kullanır. ICU plural rule locale'in doğru kategorisini seçebilir. Translator her category için tam mesaj yazabilir. Code yalnızca count değerini göndererek grammar kararından ayrılır.

Gender

Bazı dillerde kişi veya nesne gender bilgisi cümlenin farklı bölümlerini etkileyebilir. Cümle parçaları ayrı key'lere bölündüğünde translator bu ilişkiyi göremez. ICU select gibi yapı belirli seçenekleri tek message içinde tutabilir. Gender bilgisinin gerçekten product için gerekli olduğu durumlarda privacy ve data model de düşünülmelidir. Gereksiz gender varsayımı yapılmamalıdır.

Translator Context

Translator bir string'in nerede ve nasıl kullanıldığını bilmeden doğru tone seçmekte zorlanabilir. Parçalı message context'i daha da azaltır. Description, screenshot ve user journey bilgisi kaynakla birlikte gönderilmelidir. Placeholder'ın neyi temsil ettiği açıkça yazılmalıdır. Context translation review süresini de kısaltabilir.

Bütün Cümleyi Tek Mesaj Olarak Vermek

Whole-message yaklaşımı translator'a kelime sırasını özgürce değiştirme imkanı verir. Placeholder message içinde istenen noktaya taşınabilir. Plural veya select branch'leri tam sentence halinde tutulabilir. Source copy değiştiğinde impact tek unit üzerinde görülür. Bu model grammar açısından daha dayanıklı translation resource oluşturur.

ICU MessageFormat Nedir?

ICU MessageFormat değişken, plural ve select gibi dinamik mesaj ihtiyaçlarını locale-aware biçimde ifade etmeye yardımcı olan yaygın mesaj modelidir. Basit string interpolation'ın ötesine geçerek dil kurallarını translation resource içine taşır. Translator farklı plural category'ler veya selection branch'leri için tam cümle yazabilir. Number ve date formatting de message context içinde kullanılabilir. Kurumsal projede standard message syntax kullanmak farklı framework'lerin localization davranışını ortaklaştırmaya yardımcı olur.

Placeholder

Placeholder mesaj içindeki dinamik değeri temsil eder. Kullanıcı adı, tarih veya count örnek olabilir. Placeholder adı semantic olmalı ve translator tarafından değiştirilmemelidir. Resource validation source ve target placeholder set'lerinin aynı olduğunu kontrol edebilir. Runtime value gerektiğinde locale-aware formatter'dan geçirilmelidir.

plural

plural numeric value için locale'in plural rule kategorisine göre mesaj seçer. English yalnızca basit görünse de diğer diller daha fazla category gerektirebilir. Translator ihtiyaç duyduğu branch'leri target locale'e göre ekleyebilir. other kategorisi güvenli tamamlayıcı branch olarak önemlidir. Count cümle içine # veya placeholder ile yerleştirilebilir.

select

select sabit keyword set'i üzerinden message branch seçer. Gender, status veya user role gibi sınırlı seçenekler buna örnek olabilir. Branch sayısı domain model ile uyumlu tutulmalıdır. Unknown değer için other benzeri fallback düşünülmelidir. Logic'in tamamını translation içine taşımak yerine yalnızca grammar veya copy seçimini burada tutmak daha sağlıklıdır.

selectordinal

selectordinal ordinal number ifadeleri için locale-specific category seçimi sağlar. English 1st, 2nd gibi yapılar kullanabilir. Her dil ordinal değerleri aynı biçimde ifade etmez. String suffix'i code'da elle eklemek hatalı sonuç üretebilir. Locale-aware message rule kullanmak daha güvenli olur.

Number Formatting

ICU message içindeki number value locale'e göre formatlanabilir. Decimal separator ve grouping convention bu şekilde doğru uygulanır. Currency gibi business information yine explicit olarak sağlanmalıdır. Formatter'ın default precision davranışı domain ihtiyacına uygun olmalıdır. Financial display'de rounding rule ayrıca belirlenebilir.

Date Formatting

Date message içinde locale-aware formatter ile gösterilebilir. Tarih değerinin storage formatı translation string olmamalıdır. Runtime gerçek date veya timestamp değerini locale ve time zone ile formatlar. User time zone language'den ayrı context olarak taşınır. Tarih format pattern'ini translator'ın elle yazması yerine standard formatter kullanmak hatayı azaltır.

Pluralization Neden count === 1 Değildir?

Plural grammar dilden dile ciddi biçimde değişir. English developer için iki branch yeterli görünse de Arabic veya Polish gibi diller daha fazla category kullanır. Dil kurallarını if statement olarak application code'a gömmek yeni locale eklenmesini zorlaştırır. CLDR tabanlı plural rule sistemleri category seçimini locale'e göre yapar. Developer count değerini sağlar ve linguistic choice translation message tarafından yönetilir.

English Plural Rules

English cardinal kullanımında çoğu temel senaryoda one ve other ayrımı görülür. Bu basit yapı developer'ı bütün dillerin aynı olduğunu düşünmeye yöneltebilir. Zero değeri çoğu zaman other davranışına girer. Copy gereksinimine göre explicit =0 branch kullanılabilir. English pattern başka locale'lere doğrudan kopyalanmamalıdır.

Turkish Pluralization

Türkçe çoğul kullanımı English ile aynı code kuralına indirgenmemelidir. Sayıdan sonra ismin çoğul eki alıp almaması cümle yapısına göre doğal biçimde ele alınmalıdır. ICU locale rule gerekli category seçimini sağlar. Translator bütün cümleyi target grammar'a göre yazmalıdır. Developer Türkçe için özel string concatenation eklemekten kaçınmalıdır.

Polish Plural Rules

Polish plural grammar birden fazla numeric category gerektiren iyi örneklerden biridir. Son basamak ve sayı aralığı gibi kurallar sonucu etkileyebilir. Manuel modulo logic yazmak bakım ve test yükü yaratır. Standard plural rule sistemi bu hesabı locale data üzerinden yapar. Translator uygun branch'lerde doğal inflection kullanabilir.

Arabic Plural Categories

Arabic plural sistemi birden fazla category kullandığı için iki branch yaklaşımının sınırını açıkça gösterir. CLDR modelinde zero, one, two, few, many ve other kategorileri bulunabilir. Her mesaj bütün kategorileri aynı biçimde kullanmak zorunda olmayabilir. Library locale rule'a göre doğru branch'i seçer. Translation QA gerçek sayılarla bütün category'leri test etmelidir.

zero

zero belirli locale'lerde sıfır değerleri için ayrı grammatical category olabilir. Bu kategori her dilde bulunmaz. Product copy bazen locale rule'dan bağımsız olarak explicit zero message isteyebilir. ICU exact value ve category yaklaşımı birlikte kullanılabilir. Translator hangi davranışın business copy, hangisinin grammar rule olduğunu bilmelidir.

one

one her zaman yalnızca numeric value 1 demek değildir. Plural rule locale'e göre category membership belirler. Developer category seçimini elle yapmamalıdır. Message formatter locale bilgisini kullanır. Test fixture gerçek locale rule örnekleriyle hazırlanmalıdır.

two

Bazı diller iki değeri için ayrı category kullanır. English merkezli codebase bu ihtiyacı kolayca kaçırabilir. ICU message target locale için two branch sağlayabilir. Kaynak language'de branch gerekmese bile target translation'da gerekli olabilir. TMS message syntax'ı bu ek branch'lerin translator tarafından yönetilmesine izin vermelidir.

few

few belirli number pattern'lerinde kullanılan plural kategorilerinden biridir. Tek bir sabit sayı aralığı olarak bütün diller için tanımlanamaz. Locale rule implementation tarafından belirlenir. Translator branch'e doğru grammar formunu yazar. Developer business logic ile plural logic'i birbirinden ayırmalıdır.

many

many bazı locale'lerde belirli plural biçimlerini temsil eder. Hangi değerlerin bu category'ye girdiği locale'e bağlıdır. Test sadece 1 ve 2 değerleriyle yapılırsa branch hiç doğrulanmayabilir. Localization QA representative number set kullanmalıdır. Runtime monitoring invalid message branch problemlerini ayrıca yakalayabilir.

other

other plural message için temel fallback kategorisidir. Message syntax çoğu sistemde bu branch'in bulunmasını gerektirir. Beklenmeyen numeric pattern'ler güvenli biçimde burada karşılanır. Ancak other bütün grammar çeşitlerini tek başına çözmez. Target locale gerekli diğer category'leri de tanımlamalıdır.

Gender ve Context İçeren Mesajlar

Gender veya context'e göre değişen mesajlar string parçalarını birleştirmek yerine message-level selection ile yönetilmelidir. Bazı dillerde grammar yalnızca pronoun değil verb veya adjective biçimini de etkileyebilir. Formal ve informal hitap da locale veya product tone'a göre değişebilir. Translator'ın user journey ve variable anlamını görmesi gerekir. Gereksiz personal attribute toplamadan mümkün olan en nötr ve doğal copy tercih edilmelidir.

select

select sınırlı keyword değerlerine göre farklı mesaj branch'i seçebilir. Status, tone veya grammatical context için kullanılabilir. Branch'ler mümkünse tam sentence olmalıdır. Nested plural gerektiğinde syntax okunabilirliği korunmalıdır. Çok fazla business rule translation message içine taşınmamalıdır.

Grammatical Gender

Grammatical gender bazı dillerde isim ve sıfat biçimlerini etkileyebilir. Product modelde kişinin gender bilgisinin bulunması her zaman gerekli veya uygun değildir. Dil mümkün olduğunda neutral construction kullanabilir. Gerektiğinde translator'a context sağlanmalıdır. Data privacy ve inclusivity kararları localization ihtiyacından ayrı product değerlendirmesi gerektirir.

Formal/Informal Hitap

Bazı diller kullanıcıya formal ve informal hitap arasında açık ayrım yapar. Ürün voice guideline hangi formun kullanılacağını belirlemelidir. Aynı locale içinde B2B ve consumer ürün tonu farklı olabilir. Glossary ve style guide bu kararı bütün translator'lara aktarır. Ekranlar arasında rastgele hitap değişimi kullanıcı güvenini azaltır.

Translator'a Yeterli Context Vermek

Tek başına “Save” kaynak mesajı bunun noun mu action mı olduğunu açıklamayabilir. Screenshot ve description translator'a daha iyi karar verme imkanı verir. Placeholder örnek değeri context'i güçlendirir. Character limit gerçek tasarım kısıtıysa belirtilmelidir. Context metadata source string kadar versionlanabilir olmalıdır.

Cümle Parçalarını Birleştirmemek

Gender veya formal hitap içeren cümleyi birkaç key'e bölmek grammar kontrolünü kaybettirir. Translator parçalar arasındaki ilişkiyi göremez. Tam message branch'leri daha doğal sonuç sağlar. Tekrar eden kelimeleri azaltmak için linguistic doğruluktan vazgeçilmemelidir. Translation memory zaten benzer segmentleri yeniden kullanabilir.

Rich Text Translation Nasıl Yönetilmeli?

Link, vurgu veya inline component içeren mesajlar düz text'ten daha dikkatli yönetilmelidir. Translator'a ham ve sınırsız HTML vermek markup hatası veya güvenlik riski doğurabilir. Component placeholder yaklaşımı güvenli elementleri message içine kontrollü biçimde yerleştirebilir. Cümlenin tamamı translator tarafından yeniden sıralanabilmelidir. Runtime untrusted translation content'ini doğrudan HTML olarak inject etmemelidir.

HTML'i String İçine Gömmek

Translation string içinde serbest HTML saklamak başlangıçta pratik görünebilir. Translator tag'i yanlış kapatabilir veya desteklenmeyen markup ekleyebilir. Sanitization ve XSS riski ayrıca doğar. Rich text ihtiyacı sınırlı component placeholder sistemiyle çözülmelidir. HTML gerekiyorsa allowlist ve güvenilir publishing workflow kullanılmalıdır.

Component Placeholder

Component placeholder link veya strong gibi güvenli UI parçalarını message içinde işaretleyebilir. Translator elementin cümledeki konumunu değiştirebilir. Application gerçek component'i runtime'da kontrollü biçimde render eder. Placeholder isimleri semantic olmalıdır. Translation validation açılan ve kapanan placeholder yapısını kontrol etmelidir.

Link İçeren Cümle

“Şartları okuyun” gibi link içeren cümle target language'de farklı kelime sırası gerektirebilir. Link text'i ayrı key olarak birleştirmek doğal çeviriyi zorlaştırır. Bütün cümle tek rich message olarak tutulabilir. Translator link placeholder'ını uygun kelime grubuna yerleştirir. Destination URL application code tarafından sağlanarak translation'dan ayrılır.

Translator'ın Markup'ı Bozmasını Önlemek

TMS translator'a yalnızca desteklenen placeholder ve markup token'larını düzenlenebilir biçimde göstermelidir. Syntax validation approval öncesinde çalışabilir. Unknown tag veya eksik closing token CI tarafından reddedilebilir. Preview ekranı gerçek component rendering'ini gösterebilir. Böylece production'da broken markup riski azalır.

XSS Güvenliği

Translation resource güvenilir sistemden geliyor olsa bile HTML injection surface olarak değerlendirilmelidir. Kullanıcı veya vendor tarafından değiştirilebilir content doğrudan innerHTML benzeri API'ye verilmemelidir. Component interpolation default escaping davranışını korumalıdır. Rich text allowlist sınırlı tutulmalıdır. Translation platform access control da supply-chain güvenliğinin parçasıdır.

Placeholder Yönetimi

Placeholder dynamic data ile translated message arasında tanımlı bir contract oluşturur. {name}, {count} ve {date} gibi alanlar semantic isim taşımalıdır. Target translation bu placeholder'ları silmemeli veya yanlış adla değiştirmemelidir. CI source ve target placeholder set'lerini karşılaştırabilir. Type-safe message API eksik runtime value problemlerini geliştirme aşamasında azaltabilir.

{name}

{name} kullanıcı veya entity display name değerini temsil edebilir. Translator placeholder'ı cümlede uygun konuma taşıyabilir. Name üzerinde gereksiz case conversion yapılmamalıdır. Bidi content ihtiyacı varsa direction isolation uygulanmalıdır. Display name'in trusted HTML olmadığı unutulmamalıdır.

{count}

{count} çoğunlukla plural message'ın numeric input'udur. Count string concatenation ile noun'un yanına sabitlenmemelidir. Locale formatter grouping veya digit sistemi uygulayabilir. Message category seçimi gerçek numeric değere göre yapılır. Translator count'un neyi saydığını description içinde görebilmelidir.

{date}

{date} ham localized string yerine gerçek temporal value olarak formatter'a verilmelidir. Locale ve time zone ayrımı korunmalıdır. Date placeholder'ın hangi time zone'da gösterileceği message context'te açıklanabilir. Translator elle tarih format pattern'i yazmak zorunda kalmamalıdır. Test farklı locale ve DST sınırlarını kapsayabilir.

Placeholder Type Safety

Translation key'in hangi placeholder'ları beklediği type sistemine aktarılabilir. Developer eksik count verdiğinde compile-time hata alınabilir. Generated type'lar resource schema'dan üretilebilir. Dynamic key kullanımının fazla olması type safety'yi azaltır. Public translation helper mümkün olduğunca known key union kullanmalıdır.

Eksik Placeholder

Target translation source placeholder'ı kaldırırsa kullanıcıya kritik bilgi gösterilmeyebilir. Runtime bunu sessizce kabul etmek yerine build veya publishing aşamasında hata üretmelidir. Optional placeholder gerçekten gerekiyorsa message contract bunu açıkça modellemelidir. TMS validation translator'a sorun daha review sırasında gösterilebilir. Eksik placeholder production fallback'e bırakılmamalıdır.

Translator Tarafından Değiştirilen Placeholder'ı CI'da Yakalamak

Translator {count} değerini yanlışlıkla {number} yapabilir. CI source ve target message AST'lerini karşılaştırarak bu farkı bulabilir. Sadece regex kullanmak complex ICU syntax'ta yeterli olmayabilir. Message parser üzerinden structural validation daha güvenilirdir. Hata approval sürecini bloke ederek runtime exception'ı önleyebilir.

Locale Detection Nasıl Yapılmalı?

Locale detection birden fazla sinyali açık öncelik sırasıyla değerlendirmelidir. URL explicit kullanıcı intent'i taşıyorsa genellikle en güçlü kaynaklardan biridir. Authenticated user preference ve tenant default sonraki katmanlarda kullanılabilir. Cookie ve Accept-Language daha çok başlangıç tahmini sağlar. Sonuç her zaman desteklenen locale listesine normalize edilmelidir.

URL

URL içinde locale bulunması shareable ve deterministic navigation sağlar. Server ilk request sırasında locale'i doğrudan görebilir. SEO alternate page modeliyle de uyumludur. Kullanıcı aynı link'i başka cihazda açtığında aynı language varyantını görür. URL locale değeri allowlist üzerinden doğrulanmalıdır.

User Profile

Authenticated kullanıcı explicit language preference'ını profile içinde saklayabilir. Bu tercih farklı cihazlarda korunabilir. URL explicit locale taşıyorsa conflict politikası açık olmalıdır. Profile preference navigation sırasında URL'yi normalize etmek için kullanılabilir. Kullanıcı switch yaptığında preference güncellenebilir.

Cookie

Cookie anonymous kullanıcının son language seçimini saklamak için yararlı olabilir. Server request sırasında okunabildiği için initial render'da wrong-language flash azaltılabilir. Consent ve privacy politikası cookie türüne göre değerlendirilmelidir. Cookie tek source of truth olmak zorunda değildir. URL açık locale taşıyorsa genellikle daha doğrudan sinyal sunar.

Accept-Language

Accept-Language browser'ın tercih edilen diller hakkında gönderdiği HTTP header'dır. İlk ziyarette uygun locale tahmini yapmak için değerlidir. Kullanıcının gerçek ve kalıcı tercihi olduğu varsayılmamalıdır. Browser kurumsal cihaz policy'si nedeniyle farklı ayarlanmış olabilir. Header sonucu desteklenen locale'lerle language matching üzerinden eşleştirilmelidir.

Organization/Tenant Default

Enterprise uygulamada organization belirli default language belirleyebilir. Yeni kullanıcı ilk girişte bu tercihle başlayabilir. User explicit override yaptıysa organization default daha düşük öncelikte kalmalıdır. Tenant locale ile tenant market aynı olmak zorunda değildir. Admin değişikliği mevcut kullanıcı tercihlerini zorla değiştirmemelidir.

Application Default

Hiçbir sinyal uygun locale üretmezse application default kullanılır. Default value configuration içinde açıkça tanımlanmalıdır. Kodun farklı noktalarında farklı fallback language bulunmamalıdır. Public SEO URL'lerinde default locale prefix politikası ayrıca belirlenebilir. Monitoring default fallback oranının beklenenden yüksek olup olmadığını gösterebilir.

Önerilen Locale Resolution Sırası

Locale resolution sırası deterministic olduğunda aynı input her zaman aynı sonucu üretir. Explicit kullanıcı intent'i otomatik tahminden önce değerlendirilmelidir. Authenticated preference tenant default'undan daha kişiseldir. Cookie ve browser header ilk kullanım için yardımcı sinyallerdir. Son adımda her zaman güvenli application default bulunmalıdır.

1. Explicit URL Locale

URL locale taşıyorsa kullanıcı veya paylaşan kişi belirli language varyantını açıkça seçmiştir. Resolver önce bu değeri validate eder. Desteklenmeyen locale 404, redirect veya yakın locale fallback politikasına göre işlenebilir. Geçerli locale request context'e yazılır. Client ve server aynı URL değerini kaynak olarak kullanmalıdır.

2. Kullanıcının Kaydedilmiş Tercihi

URL locale içermiyorsa authenticated user preference güçlü ikinci sinyaldir. Profile değeri supported locale listesine göre doğrulanır. Eski veya artık desteklenmeyen value varsa fallback uygulanır. Navigation locale-prefixed URL'ye redirect edilebilir. Preference manuel switch sonrasında güncellenmelidir.

3. Tenant/Organization Tercihi

User-specific tercih yoksa organization default iyi başlangıç noktası olabilir. Enterprise onboarding sırasında tenant yöneticisi bu değeri seçebilir. Tenant default bütün kullanıcıları zorunlu biçimde kilitlememelidir. Market-specific content resolution ayrı configuration kullanabilir. Organization locale'nin değişmesi audit edilebilir yönetim işlemi olabilir.

4. Cookie

Anonymous veya logout durumunda cookie önceki explicit seçimi hatırlayabilir. Cookie value supported list ile validate edilmelidir. Eski locale kaldırıldığında cookie temizlenebilir veya normalize edilebilir. Server-side rendering cookie'yi initial request'te kullanabilir. URL oluştuğunda cookie daha düşük priority'de kalır.

5. Accept-Language

Önceki kişisel sinyaller bulunmadığında browser header uygun tahmin sağlar. Language range'leri quality değerleriyle gelebilir. Matcher desteklenen locale listesinde en uygun karşılığı bulur. Exact region bulunmazsa base language kullanılabilir. Kullanıcıya sonuç üzerinde her zaman manuel kontrol verilmelidir.

6. Default Locale

Bütün resolution adımları sonuç üretmezse default locale seçilir. Default production config'te zorunlu olmalıdır. Bu değer translation coverage açısından en güvenilir locale olmalıdır. Fallback telemetry bu noktaya ne kadar sık gelindiğini ölçebilir. Beklenmedik artış upstream locale resolution problemine işaret edebilir.

Accept-Language Tek Başına Yeterli mi?

Hayır, Accept-Language yalnızca browser veya cihaz preference'ından türeyen bir tahmindir. Shared device üzerinde gerçek kullanıcı tercihi farklı olabilir. Çok dilli kullanıcı ürün bağlamına göre başka dil seçmek isteyebilir. Explicit language switch browser header'dan daha güçlü sinyal olmalıdır. Seçim profile veya cookie içinde persist edilerek sonraki oturumlarda korunabilir.

Browser Preference Bir Tahmindir

Browser language kullanıcı tarafından hiç değiştirilmemiş olabilir. Kurumsal cihaz default'u English iken kullanıcı Türkçe tercih edebilir. Header yalnızca initial onboarding için yardımcı sinyal olarak görülmelidir. Kullanıcıya switcher sunulması zorunludur. Analytics header ile explicit selection arasındaki farkı ölçebilir.

Shared Device Problemi

Aynı cihazı birden fazla kullanıcı kullanabilir. Browser preference bütün kullanıcılar için ortaktır. Authenticated profile kişisel tercihi daha doğru temsil eder. Logout sonrası cookie privacy politikasına göre temizlenebilir veya anonymous preference olarak kalabilir. Locale resolution kullanıcı identity lifecycle'ıyla birlikte tasarlanmalıdır.

Çok Dilli Kullanıcılar

Bir kullanıcı birden fazla dili rahatlıkla kullanabilir. Browser preference sırası çalışma bağlamını her zaman yansıtmaz. Kullanıcı belirli tenant veya content için başka locale seçebilir. Explicit switch state'i profile'da saklanmalıdır. Dil seçimini “bir kere otomatik bulduk, artık değişmez” şeklinde tasarlamak yanlış olur.

Explicit User Override

Language switch kullanıcının doğrudan niyetini ifade eder. Bu seçim otomatik detection sonucundan daha yüksek öncelikte olmalıdır. Switch current route'un equivalent locale URL'sine gitmelidir. Seçim user profile ve gerekli cookie'ye yazılabilir. User override kolayca geri değiştirilebilir olmalıdır.

Tercihi Persist Etmek

Authenticated kullanıcı tercihi server profile içinde saklanabilir. Anonymous kullanıcı cookie üzerinden hatırlanabilir. Persistence yalnızca locale identifier tutmalı, gereksiz kişisel veri içermemelidir. User setting değiştiğinde cache invalidation gerekebilir. Farklı frontend'ler aynı preference contract'ını paylaşabilir.

IP Adresine Göre Dil Seçmek Doğru mu?

IP geolocation kullanıcı dilini kesin biçimde göstermez. İnsanlar seyahat edebilir, VPN kullanabilir veya çok dilli ülkelerde yaşayabilir. Location market için zayıf bir sinyal olabilir fakat language preference'ın yerine geçmemelidir. Arama motorları da locale-adaptive IP davranışlarında bütün varyantları keşfetmekte zorlanabilir. En iyi yaklaşım IP bilgisini gerekirse öneri üretmek için kullanıp kullanıcıya açık override sağlamaktır.

Location ile Language Aynı Şey Değildir

Bir kişinin bulunduğu ülke konuşmak istediği dili belirlemez. Turist, expat veya remote worker farklı language tercihine sahip olabilir. Çok dilli ülkelerde tek ülke kodundan bir dil çıkarmak zaten hatalıdır. Market pricing ile UI language ayrı state olmalıdır. Locale resolver location sinyalini düşük ağırlıkta değerlendirmelidir.

VPN

VPN kullanıcının IP konumunu farklı ülke gibi gösterebilir. Buna dayanarak zorunlu language redirect yapmak kullanıcıyı yanlış locale'e gönderir. Kullanıcı explicit seçimini korumak daha güvenlidir. Fraud veya security amaçlı geolocation başka domain concern'dür. i18n resolver bu sinyali kesin gerçek olarak kabul etmemelidir.

Seyahat Eden Kullanıcı

Kullanıcı seyahat ettiğinde IP değişir fakat dil tercihi çoğunlukla aynı kalır. Her ülke değişiminde interface language'in otomatik değişmesi rahatsız edici olur. Persist edilmiş user preference korunmalıdır. Market veya tax context gerekiyorsa ayrı seçim veya hesap bilgisi kullanılabilir. Location change yalnızca ilgili olduğunda öneri gösterebilir.

Çok Dilli Ülkeler

Birçok ülkede birden fazla yaygın veya resmi dil bulunur. IP yalnızca ülke seviyesinde bilgi verse bile doğru language seçemez. Browser header veya user preference daha iyi sinyaldir. Language switch herkes için görünür kalmalıdır. Geo-based hard redirect çok dilli pazarlarda özellikle sorunludur.

IP'yi Market Sinyali Olarak Kullanmak

IP bazı anonymous commerce akışlarında market önerisi için kullanılabilir. Bu durumda kullanıcıya “Bölgeniz şu mu?” şeklinde değiştirilebilir öneri sunmak daha güvenlidir. Billing country veya shipping destination daha sonra daha güçlü business source haline gelir. Market seçimi language'i zorla değiştirmemelidir. SEO crawler için URL varyantları IP'den bağımsız erişilebilir olmalıdır.

Language Switcher Nasıl Tasarlanmalı?

Language switcher kullanıcıya açık, erişilebilir ve tahmin edilebilir kontrol sunmalıdır. Dil isimleri mümkün olduğunca kendi dilinde gösterilebilir. Bayraklar language ile country kavramını karıştırdığı için tek başına dil simgesi olmamalıdır. Switch current page'in equivalent locale sürümünde kalmayı hedeflemelidir. Seçim profile'a kaydedilerek sonraki ziyaretlerde korunabilir.

Dil Adını Kendi Dilinde Göstermek

Kullanıcı mevcut interface dilini okuyamıyorsa language listesinde hedef dili yine de bulabilmelidir. Bu nedenle “Türkçe”, “Deutsch” veya benzeri native label kullanımı faydalıdır. Gerekirse yanında current UI dilindeki açıklama da gösterilebilir. Script farklıysa font coverage kontrol edilmelidir. Liste sıralaması locale-aware veya product-defined olabilir.

Bayrağı Dil Simgesi Olarak Kullanmamak

Bir bayrak ülkeyi temsil eder, language'i değil. İngilizce veya İspanyolca çok sayıda ülkede kullanılır. Tek bayrak seçmek bazı kullanıcıları yanlış temsil edebilir. Language switcher text label üzerinden daha açık çalışır. Market seçici gerekiyorsa ayrı country veya region kontrolü tasarlanabilir.

Mevcut Sayfada Kalmak

Kullanıcı ürün detayındayken dili değiştirdiğinde ana sayfaya gönderilmemelidir. Router equivalent resource'un hedef locale URL'sini üretmelidir. Localized slug kullanılıyorsa mapping content ID üzerinden yapılabilir. Hedef içerik yoksa açık fallback davranışı gösterilmelidir. Bu detay language switch'i gerçek navigation feature haline getirir.

Seçimi User Profile'a Kaydetmek

Authenticated kullanıcı dil değiştirince profile preference güncellenebilir. Update başarısız olursa interface yine current session boyunca seçilen locale'i kullanabilir. Preference sync error telemetry ile izlenebilir. Organization default kişisel seçimin üzerine yazmamalıdır. Privacy açısından yalnızca gerekli locale identifier saklanmalıdır.

Keyboard ve Screen Reader Erişilebilirliği

Language switcher gerçek button, menu veya select semantics'i kullanmalıdır. Keyboard ile bütün seçeneklere erişilebilmelidir. Active locale screen reader'a anlaşılır biçimde belirtilmelidir. Dil isimlerinin kendi lang attribute değerleri doğru telaffuza yardımcı olabilir. Focus locale switch sonrası anlamsız biçimde kaybolmamalıdır.

Locale Fallback Stratejisi

Fallback, exact locale için message bulunmadığında hangi kaynağın kullanılacağını belirler. Zincir açık ve deterministic olmalıdır. Örneğin pt-BR önce pt, sonra default English kaynağına düşebilir. Her content türü fallback'e uygun değildir. Legal ve compliance mesajları için missing translation production error veya blocked release oluşturabilir.

Exact Locale

Resolver önce kullanıcının seçtiği exact locale resource'una bakmalıdır. Region-specific translation varsa en doğru içerik burada bulunur. Cache key exact locale değerini korumalıdır. Missing key yalnızca bu seviyede yok diye hemen raw key göstermemelidir. Sonraki fallback adımı tanımlı policy üzerinden çalışır.

Base Language

Exact locale bulunmadığında base language uygun fallback olabilir. es-MX için generic es resource birçok UI message'ı kurtarabilir. Market-specific legal copy bu kurala dahil edilmemelidir. Base translation'ın gerçekten bütün region'larda anlaşılır terminology kullandığı doğrulanmalıdır. Fallback telemetry exact locale coverage eksikliğini görünür tutmalıdır.

Default Language

Base language de yoksa application default language son user-facing fallback olabilir. Bu yaklaşım boş ekran veya raw key yerine anlaşılır metin sağlar. Ancak mixed-language experience artabileceği için telemetry önemlidir. Critical locale'lerde fallback rate için SLO tanımlanabilir. Legal content bu genel zincirin dışında tutulabilir.

pt-BR → pt → en

Bu örnek exact, base ve default fallback ilişkisini açıkça gösterir. Resolver önce Brazilian Portuguese kaynağını arar. Key bulunmazsa generic Portuguese denenir. Son olarak English default kullanılabilir. Zincir configuration üzerinden tanımlanmalı ve uygulamanın farklı noktalarında elle tekrar yazılmamalıdır.

Deterministic Fallback

Aynı locale ve key her request'te aynı fallback sonucunu üretmelidir. Random veya loading sırasına bağlı resource selection debug sürecini zorlaştırır. Server ve client fallback chain aynı olmalıdır. Translation version değiştiğinde sonuç explicit version ile izlenebilir. Deterministic sistem missing key incident'lerini yeniden üretmeyi kolaylaştırır.

Hangi Metinlerde Fallback Kullanılmamalı?

Bazı metinlerde yanlış dil göstermek hiç göstermemekten daha riskli olabilir. Legal, privacy, payment ve safety içeriği market-specific onay gerektirebilir. Bu tür content normal generic fallback zincirinden çıkarılmalıdır. Translation hazır değilse feature veya locale rollout bloke edilebilir. Governance sistemi content type'a göre farklı fallback politikası desteklemelidir.

Legal Terms

Legal terms belirli jurisdiction ve language version için onaylanmış olabilir. Başka locale metnini sessizce göstermek doğru değildir. Document ID, version ve effective date saklanmalıdır. Kullanıcı hangi metni kabul ettiğinin audit kaydına sahip olmalıdır. Missing legal translation release gate oluşturabilir.

Privacy Notice

Privacy notice veri işleme uygulamalarını kullanıcıya açıklayan kritik içeriktir. Market veya regulation'a göre farklı version gerekebilir. Generic fallback yalnızca legal ekibin açıkça onayladığı durumda kullanılmalıdır. User consent version ile ilişkilendirilebilir. Translation publish işlemi audit log'a yazılmalıdır.

Payment Disclosure

Payment disclosure ücret, renewal veya işlem koşullarını açıklayabilir. Yanlış locale veya market copy kullanıcı kararını doğrudan etkileyebilir. Currency ve amount translation string içinde hard-code edilmemelidir. Onaylı content exact market context ile çözülmelidir. Missing message transaction'ı durdurmayı gerektirebilir.

Safety Message

Safety message kullanıcı davranışını etkileyen kritik bilgi taşıyabilir. Otomatik veya düşük kaliteli fallback anlam kaybı yaratabilir. Approved translation olmadan locale rollout yapılmaması daha güvenlidir. UI message görünürlüğü de visual regression ile test edilmelidir. Monitoring message load failure durumunu yüksek severity ile raporlayabilir.

Compliance Content

Compliance content organization veya jurisdiction requirement'ına bağlı olabilir. Normal marketing copy ile aynı review akışında yönetilmemelidir. Locale ve market ikisi de content resolution'da kullanılabilir. Approval role ve audit trail zorunlu hale getirilebilir. Translation değişikliği code deployment'tan bağımsız olsa bile governance gate korunmalıdır.

Missing Translation Yönetimi

Missing translation kaçınılmaz bir operasyon durumudur fakat kullanıcıya nasıl yansıyacağı planlanmalıdır. Development ortamında hata görünür olmalıdır. Staging eksikleri warning ve dashboard üzerinden göstermelidir. Production uygun content için fallback kullanırken telemetry üretmelidir. Raw translation key kullanıcı deneyimine sızmamalıdır.

Development'ta Fail Loud

Developer yeni key eklediğinde local ortam eksik resource'u açıkça göstermelidir. Console warning tek başına gözden kaçabilir. Test veya dev overlay daha güçlü feedback sağlar. Critical namespace'de missing key build'i bile durdurabilir. Erken hata localization debt'in büyümesini önler.

Staging'de Warning

Staging gerçek translation artifact'larını kullanarak completeness kontrolü yapmalıdır. Eksik key UI üzerinde belirgin marker ile gösterilebilir. QA hangi locale'in release'e hazır olmadığını dashboard'dan görebilir. Warning telemetry TMS item'ına bağlanabilir. Production'daki sessiz fallback'ten önce sorun çözülmelidir.

Production'da Fallback + Telemetry

Normal UI copy için production fallback kullanıcıyı tamamen kırık experience'dan koruyabilir. Her fallback event metric olarak sayılmalıdır. Locale, namespace ve key metadata yeterli debugging context sağlar. Hassas user data loglanmamalıdır. Fallback rate belirli threshold'u aşarsa alert oluşturulabilir.

Raw Translation Key'i Kullanıcıya Göstermemek

billing.invoice.download gibi raw key kullanıcı için anlamsızdır. Missing translation durumunda default language veya safe generic message tercih edilmelidir. Development marker production'a taşınmamalıdır. Raw key screenshot'ları localization kalitesi üzerinde olumsuz güven oluşturur. UI layer güvenli fallback olmadan render yapmamalıdır.

Missing-Key Alert

Missing key event'i yalnızca log dosyasında kaybolmamalıdır. Locale ve release version bazında metric üretilebilir. Yeni deployment sonrası ani artış otomatik alarm oluşturabilir. Alert ilgili namespace owner'a yönlendirilebilir. TMS veya issue tracker ile otomatik ticket oluşturmak response süresini azaltabilir.

Date ve Time Localization

Tarih ve saat localization'ı translation string değiştirmekten tamamen farklı bir formatting problemidir. Aynı timestamp farklı locale'lerde farklı sıra ve saat formatıyla gösterilebilir. Time zone kullanıcı tercihinden veya event bağlamından gelir. Backend veriyi güvenilir timestamp olarak saklamalıdır. Display aşamasında locale ve time zone birlikte formatter'a verilmelidir.

Locale-Aware Date Formatting

Intl.DateTimeFormat gibi platform API'leri locale-aware date output üretir. Manual DD/MM/YYYY string birleştirme yeni locale'lerde hata oluşturabilir. Display style short veya long gibi semantic option'larla tanımlanabilir. Formatting helper'ı bütün ürün genelinde ortak kullanılmalıdır. Snapshot test sabit locale ve time zone ile deterministic çalıştırılabilir.

12/24 Saat Formatı

Kullanıcıların 12 veya 24 saat tercihleri locale'e göre değişebilir. Locale default iyi başlangıç sağlar. Bazı ürünlerde user explicit time format preference seçebilir. Bu preference language seçimiyle zorla bağlanmamalıdır. Formatter hour cycle option üzerinden merkezi olarak yönetilebilir.

Tarih Alanlarının Sırası

Gün, ay ve yıl sırası bölgelere göre farklıdır. Numeric date'i elle sabit sırayla yazmak kullanıcı için belirsizlik yaratabilir. Month name içeren format bazı kritik ekranlarda daha anlaşılır olabilir. Locale formatter doğru sıralamayı sağlar. Input parsing için display formatından ayrı güvenilir date picker veya ISO contract kullanılmalıdır.

Time Zone

Time zone locale'den bağımsız bir kullanıcı veya event özelliğidir. Aynı locale kullanıcıları farklı saat dilimlerinde yaşayabilir. Event kendi source time zone'una sahip olabilir. Product hangi context'in kullanılacağını açıkça belirlemelidir. Time zone abbreviation belirsiz olabileceği için gerekli durumlarda açık zone adı gösterilebilir.

UTC Storage

Timestamp'leri normalized instant olarak saklamak birçok sistemde güvenilir temel sağlar. UTC storage display time zone seçimini daha sonra yapmaya imkan verir. Bununla birlikte “her gün saat 09:00 yerel saat” gibi recurring schedule domain'i yalnızca UTC instant değildir. Business model temporal semantics'i doğru tanımlamalıdır. Translation katmanı storage kararını değiştirmemelidir.

User Time Zone'da Display

User-specific event'ler çoğu zaman kullanıcının time zone'unda gösterilebilir. Organization dashboard bazı durumlarda organization time zone kullanabilir. Event original zone önemliyse ikincil bilgi olarak sunulabilir. Daylight saving transition test edilmelidir. Kullanıcıya hangi zone'un gösterildiği anlaşılır biçimde belirtilmelidir.

Time Zone ile Locale Aynı Şey midir?

Hayır, time zone ve locale farklı kavramlardır. Locale language ve formatting preference bağlamını temsil eder. Time zone belirli instant'ın yerel saat karşılığını belirler. Türkçe kullanan bir kişi Berlin veya New York'ta yaşayabilir. Bu iki alanı tek preference altında tutmak yanlış tarih gösterimine yol açabilir.

Hayır

Locale'den time zone çıkarımı yapmak güvenilir değildir. Region bilgisi bulunsa bile kullanıcı seyahat ediyor olabilir. Organization merkezi başka ülkede bulunabilir. Time zone explicit user, organization veya event property olarak tutulmalıdır. Formatter iki değeri ayrı parametre olarak almalıdır.

Kullanıcı Dilinden Time Zone Tahmin Etmemek

İngilizce language onlarca time zone'da kullanılır. Türkçe kullanıcı da Türkiye dışında bulunabilir. Browser time zone başlangıç tahmini sağlayabilir. User settings explicit override sunabilir. Language change time zone preference'ını otomatik değiştirmemelidir.

Organization Time Zone

Enterprise raporları organization'ın resmi time zone'una göre hazırlanabilir. Bu değer tenant configuration içinde tutulabilir. Kullanıcı ekranında hangi zone'un kullanıldığı açıklanmalıdır. Organization time zone user locale'den bağımsızdır. Scheduled jobs da aynı source of truth'u kullanabilir.

User Time Zone

User time zone kişisel notification veya calendar display için uygun olabilir. Browser ilk login sırasında öneri sağlayabilir. Kullanıcı profile üzerinden değiştirebilmelidir. DST behavior standard time zone database üzerinden yönetilmelidir. Sabit UTC offset kullanmak uzun süreli programlar için güvenli değildir.

Event Time Zone

Conference veya appointment kendi local time zone'una sahip olabilir. Kullanıcıya hem event local hem personal local saat göstermek bazı ürünlerde faydalıdır. Event time zone data modelde açık tutulmalıdır. Translation message zone değerini doğru placeholder ile sunmalıdır. İki tarih aynı instant'ı ifade etse bile farklı gün olarak görünebilir.

Number Formatting

Number formatting decimal separator, grouping ve notation gibi locale-dependent kuralları kapsar. Raw number string'i kaynak dil convention'ıyla oluşturmak yanlış sonuç verir. JavaScript Intl.NumberFormat bu kuralların büyük bölümünü platform locale data üzerinden uygular. Business precision ve rounding option'ları ayrıca verilmelidir. Number display ile underlying numeric value birbirinden ayrılmalıdır.

Decimal Separator

Bazı locale'ler decimal separator olarak virgül, bazıları nokta kullanır. Kullanıcıya 1.5 göstermek her yerde aynı yorumlanmayabilir. Formatter locale'e göre uygun karakteri seçer. Input parsing ayrı bir sorun olduğu için display string'i doğrudan number'a çevirmek risklidir. Form component locale-aware numeric input stratejisi kullanmalıdır.

Thousands Separator

Büyük sayı grouping separator'ı locale'e göre değişebilir. Boşluk, nokta veya virgül kullanılabilir. Manuel replace yaklaşımı farklı locale'lerde bozulur. Intl formatter grouping behavior'ını hazır yönetir. CSV export gibi machine-readable formatlarda display grouping kullanılmamalıdır.

Grouping

Digit grouping yalnızca üçlü gruplar şeklinde varsayılmamalıdır. Bazı numbering convention'larda farklı grouping pattern'leri görülebilir. Platform locale data bu ayrımı yönetir. Product compact veya ungrouped display gerektiriyorsa explicit option kullanılabilir. Financial ve analytics ekranlarında tutarlılık için formatter helper ortaklaştırılmalıdır.

Percent

Percent display sayıyı yüzde biçimine dönüştürür ve sembol konumunu locale'e göre ayarlar. Underlying value'nun 0.2 mi yoksa 20 mi olduğu API contract'ta açık olmalıdır. Translation string'e elle yüzde işareti eklemek gereksizdir. Precision business requirement'ına göre seçilmelidir. Input ve display model yine ayrı tutulmalıdır.

Scientific Notation

Scientific veya engineering notation bazı teknik uygulamalarda gerekli olabilir. Locale-aware formatter decimal ve exponent presentation'ını uygun biçimde gösterebilir. Kullanıcı kitlesi bu notation'ı anlamıyorsa compact veya standard display tercih edilebilir. Accessibility label gerektiğinde daha açıklayıcı ifade kullanılabilir. Format seçimi translation değil domain presentation kararıdır.

Currency Localization

Currency localization para değerinin locale'e uygun sembol, konum ve minor unit kurallarıyla gösterilmesini sağlar. Currency kodu language veya locale'den otomatik türetilmemelidir. Kullanıcının billing currency'si sözleşme veya transaction data'sından gelmelidir. Locale yalnızca bu currency'nin nasıl gösterileceğini etkiler. Rounding ve accounting format gibi business kuralları central money formatter üzerinden yönetilmelidir.

Currency ile Locale'yi Ayırmak

en-US görmek transaction'ın USD olduğu anlamına gelmez. Kullanıcı Amerikan English interface ile EUR fatura görüntüleyebilir. Money value amount ve ISO currency code birlikte taşınmalıdır. Formatter ayrıca display locale alır. Bu ayrım yanlış para birimi gösterme riskini ciddi biçimde azaltır.

Currency Symbol

Currency symbol tek başına her zaman benzersiz değildir. Aynı $ işareti farklı currency'ler için kullanılabilir. Ambiguous context'te currency code göstermek daha doğru olabilir. Intl formatter narrow veya code display seçenekleri sunabilir. Product hangi ekranın ne kadar açıklık gerektirdiğini belirlemelidir.

Symbol Position

Currency symbol bazı locale'lerde amount önünde, bazılarında sonrasında gösterilebilir. Aradaki spacing de değişebilir. String concatenation bu detayları kolayca yanlış uygular. Locale-aware currency formatter doğru order'ı sağlar. Translator currency symbol'ün yerini message içinde elle belirlememelidir.

Minor Units

Her currency iki decimal minor unit kullanmaz. Bazıları sıfır veya farklı precision kuralına sahip olabilir. Money formatter currency metadata'sını kullanmalıdır. Database amount representation floating-point hatalarına karşı ayrıca güvenli tasarlanmalıdır. UI yalnızca backend'in doğru monetary value contract'ını formatlamalıdır.

Rounding

Display rounding ve accounting rounding aynı şey olmayabilir. UI formatter business calculation yapmamalıdır. Backend hesaplanmış amount'u exact currency value olarak sağlamalıdır. Display yalnızca izin verilen precision ile sunum yapar. Rounding policy finance domain tarafından onaylanmalıdır.

Display Currency vs Billing Currency

Bazı ürünler kullanıcının tercih ettiği display currency ile gerçek billing currency'yi ayırabilir. Conversion rate ve timestamp açıkça gösterilmelidir. Display conversion user convenience sağlar fakat invoice legal value'sunu değiştirmez. Locale iki currency'nin formatını etkileyebilir. Translation copy hangi değerin yaklaşık veya gerçek olduğunu anlaşılır biçimde açıklamalıdır.

Measurement Unit Localization

Ölçü birimleri de yalnızca language translation meselesi değildir. Metric ve imperial preference market veya kullanıcı seçimine göre değişebilir. Conversion business value'nun kendisini değiştirir, translation ise label'ı yönetir. Distance, weight ve temperature için merkezi unit service kullanmak tutarlılık sağlar. Original source value ve unit saklanarak dönüşümün geri izlenebilir olması sağlanabilir.

Metric

Metric system birçok markette varsayılan ölçü sistemidir. Length, weight ve temperature display uygun unit'e çevrilebilir. Kullanıcı preference farklıysa override desteklenebilir. Conversion precision domain gereksinimine göre belirlenmelidir. Translator unit symbol üretmeye çalışmamalıdır.

Imperial

Imperial veya US customary unit'ler belirli pazarlarda kullanıcı beklentisine daha uygundur. Aynı physical value farklı unit ile gösterilebilir. Backend tek normalized measurement saklayabilir. UI display service dönüşümü yapabilir. Conversion rule localization resource'dan ayrılmalıdır.

Temperature

Celsius ve Fahrenheit dönüşümü yalnızca label değişimi değildir. Numeric value de dönüştürülmelidir. Weather veya industrial data'da precision önemlidir. Kullanıcı locale'inden otomatik unit seçimi ilk tahmin olabilir. Explicit user preference daha güçlü kaynak olmalıdır.

Distance

Distance kilometer, mile veya daha küçük unit'lerle gösterilebilir. Appropriate unit distance büyüklüğüne göre değişebilir. Formatter short veya long unit label sağlayabilir. Route veya logistics domain'i conversion accuracy'yi test etmelidir. Translation sadece sentence context'ini yönetmelidir.

Weight

Weight kilogram, pound veya başka unit ile sunulabilir. Commerce ürünlerinde shipping calculation underlying standard unit üzerinden yapılmalıdır. Display unit user preference olabilir. Input kabul ediliyorsa source unit açıkça seçilmelidir. Automatic conversion kullanıcıya görünür şekilde uygulanmalıdır.

Unit Conversion ile Translation'ı Ayırmak

Translation “kilometre” kelimesini çevirebilir fakat 10 km değerini 6.2 mile dönüştürmez. Conversion numeric domain operation'dır. Formatter ve translator farklı sorumluluk taşır. Aynı message translated text ile converted value'yu bir araya getirebilir. Bu ayrım testleri de daha kolay hale getirir.

Locale-Aware Sorting

Alphabetical sorting Unicode code point sırasına göre yapılırsa kullanıcı diline uygun sonuç vermeyebilir. Collation kuralları harflerin hangi sırada değerlendirileceğini locale'e göre belirler. JavaScript Intl.Collator bu amaçla kullanılabilir. Search normalization ile display sorting aynı algoritma olmak zorunda değildir. Türkçe gibi özel case ve harf sırası olan diller representative testlerle doğrulanmalıdır.

Alphabetical Order Her Dilde Aynı Değildir

Harf sırası ve eşdeğerlik kuralları locale'ler arasında değişir. Basit byte veya Unicode code point sort user expectation'ını karşılamaz. Accent veya case sensitivity de farklı davranabilir. Locale-aware collator doğru comparison function sağlar. Server-side sorting yapılıyorsa database collation ile frontend sonuçları tutarlı olmalıdır.

Collation

Collation metinlerin belirli language kurallarına göre sıralanması ve karşılaştırılmasıdır. Strength veya sensitivity seçenekleri application ihtiyacına göre değişebilir. Search ile directory listing farklı sensitivity kullanabilir. Locale explicit olarak verilmelidir. Default process locale'e güvenmek distributed sistemde farklı sonuçlar üretebilir.

Intl.Collator

Intl.Collator JavaScript'te locale-aware string comparison sağlar. Bir collator instance tekrar kullanılarak büyük listelerde performans iyileştirilebilir. Numeric sorting gibi seçenekler file name veya version listelerinde faydalı olabilir. Locale değiştiğinde instance yeniden oluşturulmalıdır. UI sort indicator kullanılan comparison strategy'yi yansıtmalıdır.

Turkish Sorting

Türkçe alfabede I, İ, ı ve i ilişkisi English'ten farklıdır. English-centric case normalization sıralama ve arama hatası oluşturabilir. Turkish locale ile collator kullanmak doğru davranışa yaklaşır. Backend search engine locale analyzer ayarları da uyumlu olmalıdır. Frontend ile backend sonuçları ayrı test edilmelidir.

Search ve Sort Davranışlarını Ayrı Test Etmek

Sort alfabetik sıra üretirken search kullanıcı input'u ile eşleşme bulmaya çalışır. İki davranış aynı normalization requirement'ına sahip değildir. Accent-insensitive search istenirken sort accent farkını koruyabilir. Test fixture gerçek locale karakterlerini içermelidir. Production support ticket'ları locale-specific edge case keşfi için yararlı kaynaktır.

Türkçe I/İ/ı/i Problemi

Türkçe case conversion English varsayımlarının kolayca hata ürettiği bilinen örneklerden biridir. Büyük I ile küçük ı, büyük İ ile küçük i ilişkisi locale-aware işlenmelidir. Generic toLowerCase() her search senaryosu için doğru sonuç vermeyebilir. Locale-aware case conversion ve collator kullanılabilir. User identifier gibi security-sensitive comparison ise farklı canonicalization politikasına ihtiyaç duyabilir.

Locale-Aware Case Conversion

Platform API'leri locale parametresiyle case conversion yapabilir. Türkçe için doğru locale verilmesi harf eşleşmesini değiştirir. UI search helper bunu merkezi kullanabilir. Database tarafında da benzer locale davranışı sağlanmalıdır. Frontend'de doğru, backend'de yanlış normalization kullanıcıya tutarsız sonuç gösterir.

toLowerCase() Varsayımlarının Riski

Generic lowercase işlemi dil bağımsız görünebilir fakat Unicode case mapping her locale'de aynı değildir. Search index oluştururken bu varsayım veri kaybına yol açabilir. Özellikle Türkçe isimler yanlış eşleşebilir. Locale-aware API veya search engine analyzer tercih edilmelidir. Identifier canonicalization için ise display language'den bağımsız güvenlik standardı uygulanmalıdır.

Search Normalization

Search normalization case, accent ve Unicode normalization kararlarını içerir. Her content türü aynı kuralı kullanmayabilir. Person name search ile exact product code search farklı davranmalıdır. Locale parameter search service'e açıkça aktarılabilir. Normalized form display value'nun yerine database'de gösterilmemelidir.

Case-Insensitive Comparison

Case-insensitive comparison için iki string'i basit lowercase edip karşılaştırmak her locale'de güvenli değildir. Collator sensitivity seçenekleri daha uygun olabilir. Security token veya username equality gibi alanlarda locale-sensitive comparison kullanmak da riskli olabilir. Domain hangi semantiğin gerektiğini açıkça tanımlamalıdır. UI text comparison ile identity comparison birbirine karıştırılmamalıdır.

Unicode ve UTF-8

Çok dilli uygulamanın temel encoding katmanı Unicode uyumlu olmalıdır. UTF-8 web için güçlü varsayılan encoding sağlar. Frontend, backend, database ve export pipeline aynı karakterleri kayıpsız taşımalıdır. Bir katmanda legacy encoding kullanılması emoji veya CJK karakterlerinin bozulmasına yol açabilir. i18n testi yalnızca Latin karakterlerle yapılmamalıdır.

Neden UTF-8 Varsayılan Olmalı?

UTF-8 geniş Unicode karakter setini verimli biçimde temsil eder. Modern web platformu ve JSON ecosystem'iyle doğal uyum sağlar. Locale bazında farklı encoding seçme ihtiyacını ortadan kaldırır. Storage ve network pipeline daha basit olur. Legacy integration varsa conversion boundary açıkça test edilmelidir.

Frontend Encoding

HTML document UTF-8 olarak sunulmalıdır. Form input farklı script ve emoji karakterlerini koruyabilmelidir. JavaScript string'leri Unicode modelinde çalışsa da grapheme ve code point ayrıntıları bazı işlemlerde önemlidir. Character count UI'sı user-perceived character ile code unit sayısını karıştırmamalıdır. Font coverage encoding'den ayrı bir rendering problemidir.

Backend

Backend request ve response body encoding'ini doğru yönetmelidir. JSON endpoint'lerinde Unicode content kayıpsız taşınmalıdır. Log system kullanıcı text'ini bozmamalıdır. Validation ASCII-only varsayımı yapmamalıdır. Legacy downstream system'e conversion gerekiyorsa unsupported character behavior açıkça belirlenmelidir.

Database

Database column ve connection encoding Unicode karakterları desteklemelidir. Collation seçimleri search ve unique behavior'ı etkiler. Normalization form farklılıkları unique constraint üzerinde ayrıca düşünülmelidir. Migration eski veriyi bozmadan yapılmalıdır. Backup ve restore süreci de aynı encoding'i korumalıdır.

API

API contract Unicode text'i normal string olarak taşıyabilmelidir. Client gereksiz manual escape veya encoding dönüşümü yapmamalıdır. URL path içindeki localized slug uygun percent-encoding ile işlenebilir. Signature veya hash hesaplanıyorsa byte representation standardı sabit olmalıdır. Integration test farklı script örnekleri içermelidir.

CSV/File Export

CSV ve benzeri export dosyaları farklı desktop tool'larda açılabilir. UTF-8 desteği ve delimiter locale behavior'ı test edilmelidir. Bazı spreadsheet yazılımları encoding detection konusunda özel davranabilir. Export machine-readable contract ise locale-formatted number yerine raw standard representation tercih edilebilir. User-facing report ile data export ayrı amaçlara göre tasarlanmalıdır.

Unicode Normalization

Unicode'da görsel olarak aynı karakter farklı code point dizileriyle temsil edilebilir. Bu durum search, equality ve unique constraint davranışını etkileyebilir. NFC ve NFD gibi normalization formları ortak representation oluşturmak için kullanılır. Her input'u düşünmeden normalize etmek de domain requirement'ını etkileyebilir. Policy storage, search ve identity alanları için açıkça belirlenmelidir.

Görsel Olarak Aynı Farklı Code Point Dizileri

Accent içeren bir karakter tek code point veya base character plus combining mark olarak gelebilir. UI'da iki değer aynı görünebilir. Raw binary comparison farklı sonuç verebilir. Search index ve unique constraint bu durumu hesaba katmalıdır. Test fixtures composed ve decomposed örnekleri içermelidir.

NFC

NFC karakterleri mümkün olduğunca composed representation'a normalize eder. Web uygulamalarında storage veya comparison için yaygın seçenek olabilir. Normalization giriş boundary'sinde veya search indexing sırasında uygulanabilir. Original user input gerektiğinde ayrıca korunabilir. Security-sensitive identifier policy Unicode spoofing risklerini de ele almalıdır.

NFD

NFD karakterleri canonical decomposition biçimine ayırır. Bazı platform veya filesystem davranışlarında bu representation görülebilir. Application iki form arasındaki farkı kullanıcıya hata olarak yansıtmamalıdır. Search pipeline normalize ederek consistent comparison sağlayabilir. Export ve integration sistemleri hangi formu beklediğini dokümante etmelidir.

Search

Search user input ve indexed content'in aynı normalization policy'sine sahip olmasını gerektirir. Accent-insensitive behavior ayrıca language ve product requirement'ına bağlıdır. Normalization tek başına stemming veya tokenization sorunlarını çözmez. Search engine locale analyzer kullanılabilir. Frontend local filtering backend search ile aynı sonucu vermelidir.

Unique Constraint

Database unique constraint visually identical Unicode strings'i farklı kabul edebilir. User name veya slug gibi alanlarda bu beklenmeyen duplicate oluşturabilir. Normalize edilmiş secondary column kullanılabilir. Case ve script confusable riskleri ayrıca değerlendirilmelidir. Identity semantics yalnızca locale formatting'e bırakılmamalıdır.

User Input

Kullanıcı farklı keyboard ve input method üzerinden çeşitli Unicode sequence'leri üretebilir. Form validation gereksiz ASCII restriction uygulamamalıdır. Normalization kullanıcıya görünmeden kontrollü yapılabilir. Display name gibi alanlarda original form korunması önemli olabilir. Search ve comparison için ayrı normalized representation kullanılabilir.

RTL (Right-to-Left) Desteği

RTL desteği translation dosyası eklemekten çok daha geniş bir tasarım ve CSS problemidir. Arabic, Hebrew, Persian ve Urdu gibi dillerin yazı akışı sağdan sola olabilir. Layout spacing, icon direction ve mixed-language content davranışı buna göre değişir. CSS logical properties fiziksel left/right bağımlılığını azaltır. Pseudo-RTL test gerçek translation hazır olmadan layout problemlerini erkenden gösterebilir.

Arabic

Arabic script sağdan sola akar ve bağlanan harf yapısı font seçimini etkiler. Latin fallback font'u yeterli readability sağlamayabilir. Number ve embedded English text bidirectional davranış gösterebilir. UI component'leri long text ve RTL mode'da test edilmelidir. Translation yalnızca copy değil visual QA gerektirir.

Hebrew

Hebrew de RTL layout gerektiren önemli dillerden biridir. Navigation ve inline alignment fiziksel left/right üzerinden hard-code edilmemelidir. Mixed English product name'leri Bidi behavior oluşturabilir. Screen reader language metadata doğru ayarlanmalıdır. Font fallback gerekli glyph coverage'ı sağlamalıdır.

Persian

Persian Arabic script ailesini kullanır fakat language ve terminology farklıdır. Tek “Arabic RTL” translation modeline indirgenmemelidir. Locale-aware number ve date preference ayrıca değişebilir. Font'un Persian glyph quality'si kontrol edilmelidir. RTL infrastructure ortak olsa da content ve formatting locale-specific kalır.

Urdu

Urdu RTL script kullanırken typography ihtiyaçları farklılaşabilir. Bazı fontlar Nastaliq benzeri yazım beklentilerini daha iyi karşılar. Line height ve component height test edilmelidir. Text expansion yalnızca yatay değil dikey alanı da etkileyebilir. Locale QA native reviewer ile yapılmalıdır.

Translation Dosyası Eklemek Neden Yeterli Değildir?

Metin çevrilmiş olsa bile layout hâlâ soldan sağa hard-code edilmiş olabilir. Back arrow yanlış yönü gösterebilir. Padding-left ve margin-right gibi fiziksel property'ler mirror davranışını bozabilir. Form ve table alignment yeniden değerlendirilmelidir. Bu yüzden RTL readiness design system seviyesinde çözülmelidir.

RTL Sayfa Yönü

RTL language aktif olduğunda document direction mümkün olduğunca root seviyede doğru belirtilmelidir. dir browser'ın text flow ve bazı default layout davranışlarını etkiler. lang ise language bilgisini ayrı olarak sağlar. İki attribute aynı işi yapmaz. Direction script özelliğine bağlı olduğundan yalnızca region veya market üzerinden çıkarılmamalıdır.

dir=""rtl""

dir="rtl" browser'a element içeriğinin temel yönünü sağdan sola olarak bildirir. Root elementte kullanıldığında bütün application için base direction oluşturur. Nested content farklı direction gerektiğinde override edilebilir. CSS logical properties bu direction bilgisinden faydalanır. Direction'ı yalnızca CSS class ile taklit etmek semantic browser davranışlarını kaçırabilir.

lang

lang document veya element içeriğinin human language bilgisini belirtir. Screen reader telaffuzu ve bazı browser davranışları bundan faydalanır. BCP 47 uyumlu value kullanılmalıdır. RTL direction ile birlikte kullanılması gerekebilir. lang="ar" tek başına explicit direction management ihtiyacını her UI architecture'da çözmez.

HTML Root Element

Document'in temel language ve direction değeri root HTML element üzerinde ayarlanabilir. SSR sırasında server doğru locale'i bildiği için initial markup doğru attribute'larla üretilebilir. Client locale switch sonrasında bu değerler güncellenmelidir. Flash of wrong direction layout shift oluşturabilir. Root metadata source of truth locale resolver ile uyumlu olmalıdır.

Direction'ın Script Özelliği Olduğunu Unutmamak

Aynı language farklı script kullanabiliyorsa direction language code'dan basit hard-coded map ile türetilirken dikkat gerekir. Script metadata daha doğru sinyal sağlayabilir. User-generated mixed content ayrıca kendi direction'ına ihtiyaç duyabilir. Market country direction belirlemek için yeterli değildir. Locale model script bilgisini gerektiğinde korumalıdır.

CSS Logical Properties

Logical CSS properties fiziksel left ve right yerine writing direction'a göre inline başlangıç ve bitiş kavramlarını kullanır. Bu yaklaşım RTL ve LTR layout'ların aynı CSS ile çalışmasını kolaylaştırır. margin-inline-start gibi property direction değiştiğinde otomatik uygun tarafa uygulanır. Design system spacing primitive'leri logical property kullanabilir. Böylece her RTL locale için ayrı override stylesheet ihtiyacı azalır.

margin-inline-start

margin-inline-start text flow'un başladığı tarafta margin uygular. LTR'de genellikle sol, RTL'de sağ taraf olur. Icon ile label arasındaki spacing için kullanışlıdır. Fiziksel margin-left kullanımından daha direction-aware davranır. Component API directional utility'leri bu semantic üzerinden sunabilir.

margin-inline-end

margin-inline-end inline akışın bittiği tarafta spacing sağlar. Action icon veya trailing content için uygundur. RTL mode'da physical side otomatik değişir. Bu behavior duplicated RTL CSS'i azaltır. Browser support hedefleri project compatibility matrix'inde doğrulanmalıdır.

padding-inline

padding-inline inline axis'in iki tarafına padding uygular. Button ve input gibi component'lerde horizontal spacing için doğal abstraction'dır. Direction'dan bağımsız aynı semantic sonucu üretir. Top ve bottom spacing block axis property'leriyle ayrı yönetilebilir. Design token'ları logical spacing utility'lerine bağlanabilir.

inset-inline

inset-inline positioned element'lerin inline axis offset'lerini yönetir. Badge veya side action gibi directional UI parçalarında faydalıdır. Left/right değerlerini mirror etmek için ayrı RTL selector yazma ihtiyacını azaltır. Tooltip positioning library'si kendi direction modeline sahip olabilir. Custom CSS ile library positioning behavior birlikte test edilmelidir.

left/right Bağımlılığını Azaltmak

Her fiziksel left/right kullanımı hatalı değildir. Harita veya medya control gibi gerçekten fiziksel yön ifade eden durumlar vardır. Ancak text layout spacing için logical property daha uygundur. Code review guideline directional property kullanımını sorgulayabilir. Pseudo-RTL visual test kalan bağımlılıkları kolayca görünür hale getirir.

RTL'de Hangi İkonlar Mirror Edilmeli?

Her ikon RTL'de otomatik olarak mirror edilmemelidir. Navigation direction ifade eden arrow'lar çoğunlukla mirror olur. Marka ve fiziksel dünyayı temsil eden bazı semboller aynı kalır. Media controls content time direction'ına göre özel karar gerektirebilir. Icon component metadata ile directional behavior merkezi biçimde yönetilebilir.

Navigation Arrow

Navigation arrow inline flow yönünü ifade ediyorsa RTL'de mirror edilebilir. Breadcrumb separator buna örnek olabilir. Icon'u her kullanımda CSS transform ile elle çevirmek yerine semantic icon primitive kullanılabilir. Screen reader label görsel yön değişiminden etkilenmemelidir. Visual regression LTR ve RTL karşılaştırması yapmalıdır.

Back/Forward

Back ve forward ikonları kullanıcı navigation direction'ını ifade eder. RTL interface'te yönlerin mirror edilmesi çoğu zaman beklenen behavior'dır. Browser veya platform convention'ı dikkate alınmalıdır. Text label icon anlamını güçlendirebilir. History operation semantics değişmez, yalnızca visual direction uyarlanır.

Progress Direction

Step progress veya timeline flow UI writing direction ile ilişkilendirilebilir. RTL locale'de step order sağdan sola gösterilebilir. Business process gerçek chronological direction'a bağlıysa product design ayrıca değerlendirilmelidir. Arrow ve connector behavior merkezi design system component'inde çözülmelidir. User testing culturally expected flow'u doğrulayabilir.

Hangi İkonlar Mirror Edilmemeli?

Bazı ikonlar direction değil sabit object veya marka anlamı taşır. Bunları mirror etmek kullanıcı için yanlış sembol üretebilir. Icon library her asset için directional metadata tutabilir. Designer ve localization reviewer bu listeyi birlikte yönetebilir. Otomatik bütün SVG'leri scaleX ile çevirmek güvenli değildir.

Marka Logoları

Marka logosu yazı yönünden bağımsız kimlik unsurudur. RTL nedeniyle yatay olarak çevrilmemelidir. Logo içindeki localized tagline ayrı asset veya text olabilir. Brand guideline hangi varyantların desteklendiğini açıklar. Design system logo component'i direction transform uygulamasından hariç tutulmalıdır.

Saat

Saat veya clock icon fiziksel nesne temsil ettiği için genellikle mirror edilmez. Akrep ve yelkovan yönü UI reading direction'a bağlı değildir. Benzer şekilde phone veya camera gibi object icon'ları context'e göre aynı kalır. Icon semantics designer tarafından listelenebilir. Pseudo-RTL otomatik transform rule'u bu asset'leri dışarıda bırakmalıdır.

Media Controls İçin Context Kontrolü

Media previous ve next kontrolü content direction'a göre farklı anlam taşıyabilir. Video playback time her locale'de aynı temporal direction'ı kullanabilir. Slideshow ise document reading direction'ına göre mirror bekleyebilir. Tek global icon rule yeterli değildir. Component kullanım context'i directional behavior'ı belirlemelidir.

Bidirectional (Bidi) İçerik

RTL sentence içinde English product name, URL veya number bulunduğunda bidirectional text algoritması farklı direction segment'lerini birlikte düzenler. Yanlış isolation görsel sıra sorunlarına neden olabilir. User-generated içerik daha öngörülemez kombinasyonlar taşır. HTML dir="auto" ve direction isolation araçları uygun noktalarda kullanılabilir. Bidi güvenliği yalnızca layout değil okunabilirlik ve spoofing açısından da değerlendirilmelidir.

Arapça Cümle İçinde İngilizce

Arapça sentence içine English marka veya technical term girebilir. Browser Unicode Bidi algoritması temel sıralamayı yönetir. Punctuation sınırlarında şaşırtıcı sonuçlar görülebilir. Semantic markup ve isolation kullanımı readability'yi artırır. Translation QA gerçek mixed-language examples içermelidir.

E-posta Adresi

E-mail adresleri çoğunlukla soldan sağa technical token olarak okunur. RTL sentence içinde surrounding punctuation yanlış konumda görünebilir. Address ayrı bidi-isolated element içinde gösterilebilir. Copy action raw logical value'yu kullanmalıdır. Visual representation data'yı değiştirmemelidir.

URL

URL de mixed direction content içinde özel dikkat gerektirir. User-facing localized link text raw URL göstermeye tercih edilebilir. URL gösterilmesi gerekiyorsa isolation kullanılabilir. Security açısından visually confusing Unicode hostname ayrıca ele alınmalıdır. Link href gerçek canonical URL olarak kalmalıdır.

Telefon

Telefon numarası digit ve punctuation içerdiği için RTL paragraph içinde görsel sırası etkilenebilir. Number ayrı element içinde direction isolation ile gösterilebilir. Dial action normalized E.164 benzeri machine representation kullanabilir. Display formatting locale veya market'e göre değişebilir. Visual order ile stored value birbirine karıştırılmamalıdır.

Kod

Code snippet çoğunlukla soldan sağa technical content olarak kalmalıdır. RTL document içinde code block kendi direction context'ine sahip olabilir. Syntax punctuation mirror edilmemelidir. Screen reader language metadata code için ayrıca gerekebilir. Documentation component'leri RTL sayfada bu behavior'ı merkezi olarak sağlar.

dir=""auto""

dir="auto" browser'ın içeriğin ilk güçlü directional character'ına göre yön belirlemesini sağlar. User-generated kısa text için yararlı olabilir. Bütün page direction'ını auto yapmak deterministic layout'ı bozabilir. Chat bubble veya username gibi bounded content alanlarında daha anlamlıdır. Kullanım gerçek mixed-script testlerle doğrulanmalıdır.

Kullanıcı Tarafından Girilen Bidi İçerik

User-generated content system tarafından önceden bilinen language yapısına sahip değildir. Chat, comment ve display name farklı script'leri aynı anda içerebilir. Parent page RTL olsa bile kullanıcı English mesaj yazabilir. Direction isolation content'in çevredeki punctuation'ı bozmasını engellemeye yardımcı olur. Güvenlik açısından normalization ve escaping yine ayrı katmanlardır.

Chat

Chat mesajı gönderen kullanıcının tercih ettiği dilde olabilir. Bubble direction message content'e göre auto belirlenebilir. Timestamp ve sender metadata page locale'ine göre ayrı formatlanabilir. Copy-paste logical text order'ı korumalıdır. Mixed-script emoji ve URL örnekleri test edilmelidir.

Comment

Comment içerikleri global audience tarafından farklı dillerde yazılabilir. UI chrome current locale'de kalırken comment kendi language metadata'sına sahip olabilir. Automatic language detection tahmin olarak kullanılabilir. User-provided lang yoksa direction auto yardımcı olabilir. Moderation pipeline Unicode spoofing ve control character risklerini ayrıca ele almalıdır.

User Name

User name herhangi bir script veya mixed characters içerebilir. Uygulama sadece ASCII name modeline zorlamamalıdır. Display sırasında bidi isolation çevredeki UI text'ini korur. Sorting locale veya product requirement'ına göre ayrı ele alınır. Legal name ile display name farklı alanlar olabilir.

Mixed-Script Input

Mixed-script input bazı kullanıcılar için tamamen meşrudur. Product code ile local-language açıklama aynı field'da bulunabilir. Validation gereksiz biçimde tek script kuralı uygulamamalıdır. Security-sensitive identifier'larda confusable detection ayrı policy olabilir. Display content ve authentication identifier aynı validation standardını paylaşmamalıdır.

Güvenli Direction Isolation

Direction isolation user content'in parent text flow'unu etkilemesini sınırlar. Semantic HTML veya CSS isolation özellikleri kullanılabilir. Raw Unicode directional control character'larının abuse riski de düşünülmelidir. Sanitization valid text'i gereksiz biçimde bozmamalıdır. Security ve i18n test ekipleri mixed-direction fixtures paylaşabilir.

Text Expansion

Çeviri sonrasında metin kaynak dile göre daha uzun veya daha kısa olabilir. Sabit width kullanan button ve navigation bu değişimde taşabilir. Dialog ve table header gibi alanlarda wrapping behavior önceden tasarlanmalıdır. Pseudo-localization metni yapay olarak uzatarak problem translation gelmeden önce bulunabilir. Design system responsive content'i yalnızca English length'e göre optimize etmemelidir.

Çeviri Sonrası Metin Uzaması

Kısa English label başka dilde birkaç kelimeye dönüşebilir. Character sayısı tek başına pixel width tahmini değildir. Font ve script glyph genişliği de etkilidir. Container flexible sizing kullanmalıdır. Critical screen'ler en uzun expected locale ile visual testten geçirilmelidir.

Button

Button sabit width yerine content-driven minimum size kullanabilir. Label gerektiğinde wrap olacak mı yoksa component genişleyecek mi design standardı belirlemelidir. Icon ve text spacing logical property kullanmalıdır. Loading state label uzunluğunu değiştirebilir. Accessibility için text'i truncate etmek son seçenek olmalıdır.

Navigation

Top navigation sınırlı yatay alana sahiptir. Çok uzun translated menu item responsive breakpoint'i daha erken gerektirebilir. Mobile overflow menu çözümü locale-independent çalışmalıdır. Navigation label'ı yalnızca alan kazanmak için anlamsız kısaltılmamalıdır. Localization ekiplerine character guidance verilebilir.

Table Header

Table header uzun translation'larda column genişliğini ciddi biçimde etkileyebilir. Wrapping, tooltip ve responsive table strategy birlikte düşünülmelidir. Header'ı kısaltmak data anlamını kaybettirebilir. Export header ile UI header farklı presentation kullanabilir. Visual regression representative data ile yapılmalıdır.

Dialog

Dialog title ve action button'ları text expansion'a dayanıklı olmalıdır. Sabit height translated explanatory copy'yi kesebilir. Scroll area gerekiyorsa action footer erişilebilir kalmalıdır. RTL direction modal close control konumunu etkileyebilir. Pseudo-long locale dialog stories design system'e eklenebilir.

Sabit Genişlikten Kaçınmak

Content-heavy component'lerde fixed width en yaygın localization kırılmalarından biridir. Max width okunabilirlik için kullanılabilir fakat minimum content flexibility korunmalıdır. Flex ve grid layout intrinsic sizing özelliklerinden faydalanabilir. Truncation yalnızca content kaybı kabul edilebilir olduğunda kullanılmalıdır. Responsive test locale dimension'ını da kapsamalıdır.

Design System'da i18n

Design system i18n problemlerini her feature ekibinin ayrı çözmesini engelleyen en güçlü katmanlardan biridir. Button, form, modal ve navigation primitive'leri text expansion ve RTL davranışını başlangıçtan destekleyebilir. Storybook benzeri component preview ortamında long text ve RTL senaryoları tutulabilir. Design token'ları locale-specific font veya spacing ihtiyaçlarını destekleyebilir. Böylece yeni language rollout yüzlerce ekranı tek tek düzeltme projesine dönüşmez.

Localizable Components

Localizable component text'i prop veya translation key üzerinden alır ve hard-coded copy içermez. Layout variable length text'e dayanıklıdır. ARIA label da localization input'u kabul eder. Date picker locale-aware calendar ve first-day-of-week davranışını destekleyebilir. Component public API locale bilgisini gereksiz yere her prop'a yaymamalıdır.

Flexible Width

Flexible width text expansion için temel component özelliğidir. Button ve input label container content'e göre büyüyebilir. Parent layout wrapping veya responsive davranışı desteklemelidir. Minimum tap target yine korunmalıdır. Fixed dashboard grid gibi özel durumlarda overflow strategy açıkça tasarlanmalıdır.

RTL Stories

Her temel component'in RTL preview story'si bulunabilir. Direction root context üzerinden değiştirilebilir. Icon, spacing ve alignment behavior aynı fixture ile incelenir. Automated screenshot comparison regression'ı yakalar. RTL story gerçek Arabic copy olmadan da layout problemine erken sinyal verir.

Long Text Stories

Long text story translation expansion'ını simüle eder. Button, tab, table ve dialog gibi component'lerde taşma görülür. Sadece lorem ipsum kullanmak gerçek placeholder ve punctuation davranışını göstermeyebilir. Pseudo-localized source daha iyi örnek sağlayabilir. Story design review checklist'in parçası olabilir.

CJK Stories

CJK script'ler glyph width, line-break ve font fallback davranışları açısından ayrı test değeri taşır. Latin font assumption'ı burada kolayca görünür olur. Line-height ve button vertical alignment kontrol edilmelidir. Word-break CSS yanlış kullanılırsa okunabilirlik bozulabilir. Representative Japanese veya Chinese sample text kullanılabilir.

Design Tokens

Design token'ları locale-specific typography variation'ını merkezi yönetebilir. Font family, line-height veya density script bazında değişebilir. Token override component source'unu değiştirmeden uygulanır. Spacing token'ları direction-independent kalmalıdır. Token governance localization ve design ekipleriyle birlikte değerlendirilmelidir.

Font ve Typography Stratejisi

Tek bir Latin font bütün script'leri kaliteli biçimde desteklemeyebilir. Cyrillic, Arabic ve CJK glyph coverage ile typography behavior ayrı değerlendirilmelidir. Font fallback chain missing glyph sorununu önler. Büyük multi-script font package performance maliyeti yaratabilir. Locale bazlı subset veya lazy font loading dengeli çözüm sağlayabilir.

Latin

Latin script birçok Western locale için temel font set'ini oluşturur. Accent ve extended Latin coverage kontrol edilmelidir. Sadece English alphabet ile test yapmak Türkçe veya Polish karakterlerini kaçırabilir. Font fallback visual metrics farkı layout shift oluşturabilir. Webfont preload yalnızca gerçekten critical subset için kullanılmalıdır.

Cyrillic

Cyrillic glyph'lerin font family içinde gerçekten tasarlanmış olması gerekir. Automatic fallback görsel kimliği bozabilir. Bulgarian veya Serbian form varyantları typography quality açısından ayrıca değerlendirilebilir. Font license ve subset generation pipeline kapsamı kontrol edilmelidir. Visual QA native script örnekleriyle yapılmalıdır.

Arabic

Arabic bağlantılı glyph shaping gerektirir. Font selection readability ve line-height üzerinde büyük etkiye sahiptir. Browser shaping engine modern standardları desteklese de font quality belirleyicidir. Latin fallback ile karışık text baseline uyumu test edilmelidir. Locale-specific typography token gerekebilir.

CJK

CJK font dosyaları çok geniş glyph set'i nedeniyle büyük olabilir. Tek package initial webfont olarak yüklemek performance'ı olumsuz etkileyebilir. System font veya subset strategy değerlendirilebilir. Japanese ve Simplified Chinese aynı glyph görünüm tercihlerine sahip olmayabilir. Locale-specific font stack daha doğru sonuç sağlayabilir.

Font Fallback

Fallback chain primary font eksik glyph içerdiğinde güvenli alternatif sunar. Metrics farkı line-break ve layout shift oluşturabilir. System font'lar platformlar arasında farklı görünebilir. Brand-critical typography için script-specific approved fallback listesi oluşturulabilir. Emoji font'u da chain içinde ayrı davranış gösterebilir.

Font Subsetting

Subsetting yalnızca gerekli glyph gruplarını ayrı font dosyalarına bölebilir. Latin, Cyrillic veya CJK subset route ve locale'e göre yüklenebilir. Dynamic user-generated content eksik glyph ihtiyacını artırabilir. Unicode-range CSS uygun caching ile kullanılabilir. Build pipeline yeni character coverage eklenmesini test etmelidir.

Locale Bazlı Lazy Font Loading

Kullanıcı Arabic locale açmıyorsa Arabic webfont'u initial bundle'da indirmek gerekmeyebilir. Locale resolver gerekli font resource hint'ini seçebilir. Language switch sonrasında yeni font loading sırasında layout shift yönetilmelidir. Critical text için system fallback anında kullanılabilir. CDN cache font version'ını uzun süre saklayabilir.

Formların Lokalizasyonu

Form localization yalnızca label translation değildir. Name, address, phone ve postal code modelleri ülkeler arasında farklılık gösterir. Validation rule market veya actual data type'a göre belirlenmelidir. Locale kullanıcıya uygun formatting sağlarken server canonical data model kullanabilir. Form schema cultural varsayımları minimumda tutmalıdır.

İsim Alanları

Her kullanıcı first name ve last name yapısına uymayabilir. Tek full name input bazı ürünler için daha kapsayıcı olabilir. Legal requirement varsa structured name alanları ayrıca sunulabilir. Field order locale'e göre değişebilir. Display name kullanıcı tarafından ayrı seçilebilir.

Soyadı Varsayımı

Bütün kültürlerde tek bir family name modeli bulunmaz. Zorunlu last-name field bazı kullanıcıların gerçek adını temsil edemeyebilir. Validation yalnızca business necessity olduğunda uygulanmalıdır. UI açıklaması legal veya preferred name farkını belirtmelidir. Backend schema birden fazla name component'i gerektiğinde esnek tutmalıdır.

Adres

Adres formatı ülkelere göre ciddi biçimde değişir. State, province veya district alanı her markette aynı değildir. Postal code length ve placement de değişebilir. Country-aware address component gerekli field'ları dinamik gösterebilir. Shipping provider contract ayrı normalization katmanı kullanabilir.

Telefon

Telefon input language'den çok country calling code ve numbering plan ile ilişkilidir. User locale phone country için yalnızca başlangıç tahmini olabilir. International format storage daha güvenli olabilir. Display formatting country metadata ile yapılır. SMS verification gerçek number validation'ını ayrıca gerçekleştirir.

Postal Code

Postal code formatı country'ye göre farklıdır. Numeric-only validation global ürün için hatalı olabilir. Field label da market'e göre postcode veya ZIP gibi farklı terminology kullanabilir. Country selection schema behavior'ını belirleyebilir. Server validation authoritative source olarak kalmalıdır.

Tarih

Date input kullanıcı locale'ine uygun presentation sunmalıdır. Browser native date input behavior platforma göre farklı olabilir. Stored value standard date representation kullanmalıdır. Manual text parsing mümkün olduğunca sınırlanmalıdır. Ambiguous numeric date kullanıcıya açık month name veya date picker ile azaltılabilir.

Locale-Specific Validation

Validation bazı alanlarda locale değil country veya market bilgisine bağlıdır. Postal code bunun iyi örneğidir. Translation validation message'ı target language'e çevirir fakat rule business config'ten gelir. Generic regex'ler global data çeşitliliğini yanlış reddedebilir. Validation strategy gerçek source of truth'u açıkça ayırmalıdır.

Personal Name Tasarımında Kültürel Varsayımlar

Kişisel isimler internationalized form tasarımının en sık gözden kaçan alanlarından biridir. First name ve last name modeli her kullanıcıyı doğru temsil etmez. Bazı kişiler tek isim kullanabilir veya birden fazla family name taşıyabilir. Display name ile legal name aynı gereksinimi karşılamaz. Data model yalnızca gerçekten business sürecinin ihtiyaç duyduğu ayrıntıyı istemelidir.

First Name / Last Name Modeli Her Yerde Geçerli Değildir

İki zorunlu field Batı merkezli bir varsayım olabilir. Kullanıcı gerçek adını sisteme uydurmak için sahte değer girmek zorunda kalabilir. Full name field daha esnek olabilir. Legal workflow structured alan istiyorsa locale-aware form yardım metni sağlanmalıdır. Product requirement veri modelinin şeklini belirlemelidir.

Tek İsim

Bazı kullanıcıların yasal veya tercih edilen adı tek parçadan oluşabilir. Last name zorunluluğu bu kişileri bloke eder. Database nullable veya flexible schema kullanabilir. Greeting oluştururken first name varsayımı yapılmamalıdır. Display name doğrudan kullanıcı tercihi olarak saklanabilir.

Birden Fazla Family Name

Bazı naming convention'lar birden fazla family name içerir. Tek last-name field değeri yine saklayabilir fakat parsing yapılmamalıdır. Sorting için ayrı normalized metadata gerekiyorsa açık user input alınabilir. Otomatik first/last split güvenilir değildir. Full legal name tam string olarak korunmalıdır.

Display Name

Display name UI'da kullanıcıya nasıl hitap edileceğini belirleyebilir. Legal name'den bağımsız tutulması privacy ve usability açısından faydalıdır. Emoji veya farklı script desteği product policy'ye göre belirlenir. Mention veya search için normalized index ayrı oluşturulabilir. Translation system user name'i message placeholder olarak güvenli biçimde işler.

Legal Name

Legal name payment veya compliance süreçlerinde gerekebilir. Bu alan yalnızca gerçekten ihtiyaç varsa toplanmalıdır. UI field açıklaması kullanım amacını belirtmelidir. Localization legal naming requirement'ını uzman market review ile doğrulamalıdır. Display katmanı legal value'yu gereksiz yere bütün ekranlarda göstermemelidir.

Backend Sistemlerinde i18n

Frontend düzgün lokalize edilmiş olsa bile backend tarafından üretilen e-mail veya PDF yanlış dildeyse ürün deneyimi tutarlı değildir. Backend request veya job context içinde locale bilgisini doğru resolve etmelidir. Translation resource aynı terminology ve versioning modeline bağlanabilir. Scheduled jobs user locale değişikliğini nasıl ele alacağını belirlemelidir. Presentation responsibility taşıyan backend servisleri i18n architecture'ın doğal parçasıdır.

Frontend Dışındaki Localized Content

User-facing content browser dışında birçok kanalda üretilebilir. E-mail, notification ve report bunun tipik örnekleridir. Bu kanallar ayrı translation sistemine sahip olursa terminology drift oluşabilir. Shared message catalog veya TMS ortak source sağlayabilir. Channel-specific copy gerektiğinde key namespace ile ayrılabilir.

E-mail

E-mail template kullanıcının locale'i ve gerektiğinde market bilgisiyle render edilmelidir. HTML direction ve font fallback desteklenmelidir. Subject line ayrı translation key olarak tutulmalıdır. Link URL'si hedef locale route'una gitmelidir. Legal footer market-specific resolution kullanabilir.

Push Notification

Push notification sınırlı character alanına sahiptir. Translation expansion burada daha kritik hale gelir. Device locale yerine user account preference kullanılabilir. Notification tap target doğru localized route'a gitmelidir. Server scheduled push gönderirken locale snapshot politikasını belirlemelidir.

SMS

SMS encoding ve character set mesaj segment sayısını etkileyebilir. Unicode text bazı gateway'lerde farklı segment maliyeti oluşturabilir. Critical OTP mesajı gereksiz uzun copy taşımamalıdır. Locale ve phone market ayrı context'tir. Provider template approval requirement'ı locale rollout planına dahil edilmelidir.

PDF

PDF localization font embedding, pagination ve RTL layout gerektirir. Browser CSS ile çalışan typography PDF engine'de aynı sonucu vermeyebilir. Legal document version exact locale ile ilişkilendirilmelidir. Number ve date formatting server tarafında uygulanır. Visual regression representative PDF sample'larıyla yapılabilir.

Report

Report heading ve chart label localization resource kullanabilir. Data column values locale-aware formatlanabilir. Machine-readable export raw valuesi korurken human-readable PDF localized olabilir. Report scheduled job user veya organization locale'ini seçmelidir. Historical report tekrar üretildiğinde current translation mı snapshot translation mı kullanılacağı belirlenmelidir.

Scheduled Jobs

Scheduled job request context olmadan çalıştığı için locale ayrıca resolve edilmelidir. User ID veya tenant ID üzerinden preference alınabilir. Job oluşturulurken locale snapshot saklamak başka bir seçenektir. Kullanıcı preference değiştirirse hangi değerin kullanılacağı business semantics'e bağlıdır. Queue payload gereksiz localization data taşımamalıdır.

Locale Backend'e Nasıl Taşınmalı?

Backend locale bilgisine gerçekten ihtiyaç duyduğu presentation boundary'lerde erişebilmelidir. Authenticated user profile güçlü source olabilir. Explicit request header API consumer'ın locale seçmesini sağlar. Default locale son fallback olarak bulunur. Request context locale'i her business service parametresine manuel olarak eklemek yerine kontrollü context object üzerinden taşınabilir.

Request Context

Request context authenticated identity, locale ve correlation ID gibi ortak bilgileri taşıyabilir. Locale resolver request başlangıcında tek kez çalışır. Presentation service daha sonra bu değeri kullanır. Domain function'ları locale bilmiyorsa context ona taşınmamalıdır. Bu yaklaşım hidden global mutable locale state riskini azaltır.

User Profile

User profile persisted language preference için güvenilir kaynaktır. Backend notification job'ları profile üzerinden locale resolve edebilir. Profile missing ise tenant veya default fallback kullanılabilir. Account locale change audit gerektirmeyebilir fakat preference event'i cache invalidation için yayınlanabilir. Public API user profile'a erişemiyorsa explicit locale kabul edebilir.

Explicit Locale Header

API request özel locale header taşıyabilir. Header standard veya application-specific contract olarak dokümante edilmelidir. Value BCP 47 formatında validate edilir. Unsupported locale fallback veya 400 davranışına göre işlenir. Public API'de localized message contract stable machine error code'u gölgelememelidir.

Authenticated User Preference

Authenticated request'te user preference header'dan daha güçlü source olarak seçilebilir veya explicit override'a izin verilebilir. Priority product contract'ta açık olmalıdır. Browser client URL locale'i header olarak backend'e iletebilir. Server user preference ile farklılık bulursa hangi kaynağın kazanacağı deterministic olmalıdır. Silent mismatch monitoring'e sinyal verebilir.

Default Locale

Backend hiçbir locale source bulamazsa default kullanabilir. Bu value frontend default ile mümkün olduğunca aynı governance altında tutulmalıdır. Default değişikliği notification behavior'ını etkileyebilir. Configuration versionlanmalıdır. Critical job'larda missing locale validation error olarak da değerlendirilebilir.

Microservice'lerde Locale Propagation

Microservice graph içinde locale bilgisini her request'e eklemek gereksiz coupling oluşturabilir. Domain service machine-readable data üretirken locale'e ihtiyaç duymaz. Presentation veya notification service locale bağlamını kullanır. Correlation context locale taşıyabilir fakat yalnızca ilgili boundary'ye aktarılmalıdır. Bu ayrım service contract'larının language-dependent hale gelmesini önler.

Service-to-Service Call

Servisler arası çağrıda locale yalnızca downstream response user-facing content üretiyorsa gereklidir. Product catalog raw data locale-independent olabilir veya localized business content için explicit locale isteyebilir. Contract bu farkı açıkça tanımlar. Header'ı otomatik bütün servis zincirine kopyalamak ownership'i belirsizleştirir. Trace metadata debugging için locale'i ayrıca taşıyabilir.

Correlation Context

Correlation context request zincirini observability açısından bağlar. Locale debug metadata olarak bu context'e eklenebilir. Bu, domain behavior'ın locale'e bağlı olması gerektiği anlamına gelmez. Loglarda yalnızca locale identifier tutulması privacy açısından düşük risklidir. Trace analysis belirli locale'deki error oranını gösterebilir.

Locale'nin Gereksiz Her Servise Taşınmaması

Inventory quantity language'den bağımsızdır. Bu servise locale parametresi eklemek contract'ı gereksiz genişletir. Localization presentation boundary'ye yakın tutulmalıdır. Domain data localized business content taşıyorsa ayrı content service modeli kurulabilir. Clean boundary testing ve caching'i kolaylaştırır.

Presentation Boundary

Presentation boundary machine result'ı kullanıcıya anlaşılır output'a dönüştüren katmandır. Locale burada doğal input haline gelir. Error code localized message'a çevrilebilir. Date ve currency display formatı uygulanır. Domain calculation ise aynı değerleri locale'den bağımsız üretir.

Event-Driven Sistemlerde Locale

Event-driven sistemlerde kullanıcıya daha sonra notification gönderilecekse locale zamanlama açısından özel karar gerektirir. Event oluştuğunda user locale snapshot alınabilir veya job çalıştığında yeniden resolve edilebilir. İki yaklaşım farklı business semantics üretir. Event payload gereksiz presentation data ile şişirilmemelidir. Notification contract hangi locale politikasını kullandığını açıkça tanımlamalıdır.

Event'e Locale Eklenmeli mi?

Event immutable historical fact temsil ediyorsa locale her zaman bu fact'in parçası değildir. “InvoiceCreated” olayı invoice bilgisi taşır, user language ayrı preference olabilir. Ancak event sonucu gönderilecek exact legal communication için locale snapshot gerekebilir. Karar consumer semantics'e göre verilir. Genel kural olarak presentation concern domain event'e gereksiz eklenmemelidir.

User ID'den Sonradan Resolve Etmek

Job çalıştığında user profile'dan current locale alınabilir. Böylece kullanıcı language preference değişikliğinden sonra yeni bildirimler güncel dilde gelir. Profile unavailable ise fallback policy gerekir. Historical reproducibility azalabilir. Audit-critical communication için snapshot daha doğru olabilir.

E-mail Job'ında Locale

E-mail queue payload template ID ve recipient ID taşıyabilir. Locale enqueue sırasında veya worker içinde resolve edilebilir. Translation version da reproducibility için kayıt altına alınabilir. Retry sırasında translation değişirse aynı message'ın farklı version gönderilmemesi istenebilir. Idempotency ve localization birlikte düşünülmelidir.

Kullanıcı Locale'si Event Sonrası Değişirse Ne Olur?

Bu durumda business intent belirleyicidir. Marketing e-mail current preference kullanabilir. Contract acceptance confirmation event anındaki locale ve legal version'ı kullanmalıdır. Policy content type bazında tanımlanmalıdır. Implementation her notification'da ad hoc karar vermemelidir.

API Response'ları Lokalize Edilmeli mi?

Public veya multi-client API'lerde machine-readable contract'ı locale'den bağımsız tutmak genellikle daha güvenlidir. Error code stabil olur ve client kendi UI message'ını çevirebilir. Server-generated display message yalnızca convenience veya presentation API'lerinde ek alan olabilir. Bir API consumer locale bilmiyorsa localized text anlamsız olabilir. Contract'ın temel business semantics'i translated string'e bağlanmamalıdır.

Machine-Readable Error Code

Error code programmatic branching için stabil identifier olmalıdır. Translation değiştiğinde code değişmemelidir. Client analytics ve testler code'a güvenebilir. User-facing copy ayrı key mapping ile oluşturulur. Backend aynı code'u farklı locale message'larla eşleyebilir.

Localized Display Message

Bazı API'ler doğrudan end-user application için localized message döndürebilir. Locale request context'ten resolve edilir. Message yalnızca display amaçlı olmalı ve business branching için kullanılmamalıdır. Client fallback copy sağlayabilir. Public contract localization versioning davranışını dokümante etmelidir.

API Consumer'ın Locale Bilmemesi

Machine-to-machine consumer için language gereksiz olabilir. Localized error string log veya automation içinde kullanışsızdır. Structured code ve details daha doğru contract sağlar. Human-facing dashboard son katmanda çeviri yapabilir. API locale dependency'si yalnızca gerçek presentation need varsa eklenmelidir.

Public API'lerde Stable Contract

Public API consumer'ları farklı dil ve teknoloji kullanabilir. Error text değişken ve localized olduğu için stable contract olamaz. Code, field ve structured parameter'lar versioning kurallarına tabidir. Documentation örnek mesaj gösterebilir fakat programmatic dependency önermemelidir. Bu yaklaşım client localization özgürlüğünü artırır.

UI Localization'ı Client'a Bırakmak

Client error code'u kendi translation key'ine map edebilir. Böylece aynı API web, mobile ve partner UI'da farklı language sunabilir. Unknown code generic fallback message'a gider. Mapping completeness CI ile test edilebilir. Backend yalnızca field-level details gibi gerekli machine data'yı sağlar.

Database'de Çok Dilli İçerik Nasıl Saklanmalı?

UI translation ile business content'in database modeli aynı problem değildir. Product description, article veya category name içerik ekibi tarafından yönetilebilir. Locale column, translation table veya JSON localized field farklı ihtiyaçlara uygundur. CMS geniş editorial workflow için daha iyi çözüm olabilir. Data model query, ownership ve fallback gereksinimlerine göre seçilmelidir.

UI Translation ile Business Content'i Ayırmak

“Kaydet” button label developer-owned UI string'dir. Product description ise content team veya merchant-owned business content olabilir. İkisini aynı translation file'a koymak release ve ownership süreçlerini karıştırır. UI message TMS, business content CMS üzerinden yönetilebilir. Ortak locale taxonomy yine iki sistem arasında paylaşılmalıdır.

Locale Column

Her localized content row locale column taşıyabilir. Aynı entity için birden fazla row oluşturulur. Query belirli locale ve fallback sırasını uygular. Unique constraint entity ID plus locale üzerinde kurulabilir. Çok fazla join veya row count performance açısından ölçülmelidir.

Translation Table

Base entity locale-independent alanları tutar. Ayrı translation table localized title ve description gibi alanları saklar. Bu model relational integrity açısından açıktır. Fallback query biraz daha fazla join gerektirebilir. Translation lifecycle base entity'den bağımsız yönetilebilir.

JSON/JSONB Localized Fields

Tek row içinde locale-to-value map saklamak basit read pattern sağlayabilir. Dynamic locale eklemek schema migration gerektirmez. Field-level indexing ve partial update davranışı dikkat gerektirir. Çok büyük localized content object row şişmesine yol açabilir. Editorial workflow ve query ihtiyacı bu modeli sınırlar.

CMS

CMS içerik ekibinin translation, draft ve publishing workflow'unu yönetebilir. Developer source code deploy etmeden localized business content güncellenebilir. CMS locale taxonomy application ile uyumlu olmalıdır. Preview environment hedef locale sayfasını gösterebilmelidir. UI translation TMS ile CMS content arasında terminology paylaşımı gerekebilir.

Translation Table Pattern

Translation table relational database'de localized business content için sık kullanılan açık modellerden biridir. Entity temel ve language-independent alanları taşır. Translation row entity ID ve locale ile eşleşir. Unique constraint duplicate locale kaydını engeller. Fallback ve query performance gerçek kullanım hacmine göre optimize edilmelidir.

Entity Table

Entity table ID, status ve teknik metadata gibi locale-independent alanları tutar. Default language text burada saklanmak zorunda değildir. Lifecycle translation row'lardan bağımsız yönetilebilir. Delete cascade davranışı açıkça belirlenmelidir. Audit ve ownership temel entity üzerinden izlenebilir.

EntityTranslation Table

EntityTranslation localized title, description ve diğer content field'larını taşır. Entity foreign key ile bağlıdır. Locale zorunlu column olur. Translation status draft veya approved gibi metadata eklenebilir. Content workflow TMS veya CMS ile sync edilebilir.

Locale

Locale değeri BCP 47 uyumlu ve application supported taxonomy ile eşleşmelidir. Database free-text value'ları kontrolsüz kabul etmemelidir. Canonical casing normalization uygulanabilir. Locale foreign reference veya validated string olarak tutulabilir. Unsupported legacy locale migration planıyla kaldırılmalıdır.

Fallback

Query exact locale row bulamazsa base language veya default row arayabilir. Bu fallback application service içinde merkezi olmalıdır. Legal content gibi alanlarda fallback kapatılabilir. Database query tek request'te priority sırasını uygulayabilir. Telemetry fallback use rate'i ölçebilir.

Unique Constraint

Aynı entity ve locale için birden fazla active translation bulunması belirsizlik yaratır. Composite unique constraint bunu engeller. Versioned content gerekiyorsa effective version key'e eklenebilir. Draft ve published row modeli ayrıca tasarlanmalıdır. Constraint business lifecycle ile uyumlu olmalıdır.

Query Performance

Localized list page çok sayıda translation join'i yapabilir. Entity ID ve locale index query planını iyileştirir. Fallback zinciri naive N+1 query üretmemelidir. Cache frequently read translation'lara yardımcı olabilir. Performance test gerçek locale dağılımıyla yapılmalıdır.

CMS İçeriği ile UI Translation Arasındaki Fark

CMS content ve UI translation farklı ownership ve release cadence taşır. Developer-owned string code release ile birlikte değişirken content team article'ı gün içinde defalarca düzenleyebilir. TMS translation workflow'a, CMS editorial workflow'a odaklanır. İki sistem aynı locale taxonomy ve glossary'yi paylaşabilir. Sınır açık olmadığında marketer source repository'de, developer CMS ekranında gereksiz iş yapmak zorunda kalır.

Developer-Owned Strings

Button, validation ve component label source code behavior'ıyla yakından ilişkilidir. Translation key developer tarafından eklenir. Placeholder contract CI tarafından doğrulanabilir. TMS target translation'ı yönetir. Key lifecycle code versioning ile senkron tutulur.

Content-Team-Owned Content

Landing page article veya product marketing copy content team tarafından düzenlenebilir. CMS draft, preview ve scheduled publishing sağlar. Developer her metin değişikliği için deployment yapmamalıdır. Localized variants editorial workflow içinde review edilir. Content ID locale URL mapping'i için stabil kalabilir.

Release Cadence

UI feature release ile translation readiness birlikte planlanır. CMS content ise application release'ten bağımsız yayınlanabilir. İki cadence aynı pipeline'a zorlanırsa ekiplerden biri gereksiz bekler. Shared preview environment integrated experience sağlar. Production rollback politikası iki sistem için ayrı olabilir.

TMS vs CMS

TMS segment translation, glossary ve translation memory üzerinde uzmanlaşır. CMS page structure ve editorial publishing üzerinde uzmanlaşır. Bazı platformlar iki yeteneği birlikte sunabilir. Architecture logical ownership farkını yine korumalıdır. Integration content'i CMS'den TMS'e translation için gönderip geri alabilir.

Ortak Locale Taxonomy

TMS pt-BR kullanırken CMS pt_BR kullanırsa sürekli mapping gerekir. Ortak locale registry bu sorunu azaltır. Supported status ve market relation merkezi metadata olabilir. System-specific adapter gerekli format dönüşümünü sınırda yapar. Taxonomy governance yeni locale onboarding'in ilk adımıdır.

SSR ve Server Components'da i18n

Server-side rendering locale'i request'in başında çözerek kullanıcıya ilk HTML'i doğru dilde göndermeyi sağlar. Translation server üzerinde uygulanabilir. Client hydrate olurken aynı locale ve resource version'ını kullanmalıdır. Aksi halde flash of wrong language veya hydration mismatch oluşabilir. Next.js gibi server component kullanan yapılarda translation bundle'ın tamamını client JavaScript'e göndermemek ek performans avantajı sağlayabilir.

Request Başında Locale Resolve Etmek

Server URL, cookie ve request header bilgilerine erişir. Locale resolver request render başlamadan deterministic sonuç üretmelidir. HTML lang ve dir değerleri aynı context'ten gelir. Data fetching locale-dependent content istiyorsa aynı value kullanılır. Render sırasında locale'in değişmesi request isolation'ı bozar.

Server-Side Translation

Server component translation resource'u server memory veya CDN'den yükleyebilir. Result HTML içinde localized text olarak client'a gönderilir. Client yalnızca interactive component'lerin gerekli namespace'lerini alabilir. Translation load failure server error boundary ile yönetilebilir. Cache locale ve resource version'a göre ayrılmalıdır.

Client'a Aynı Locale'yi Hydrate Etmek

Server tr render ederken client default en ile başlarsa markup uyuşmaz. Initial locale serialized routing context'ten alınmalıdır. URL source of truth ise client doğrudan pathname'den de aynı değeri çıkarabilir. Translation version mismatch de text difference yaratabilir. Hydration test server ve client config'i birlikte doğrulamalıdır.

Flash of Wrong Language

Client-only locale detection sayfa ilk açıldığında default dili kısa süre gösterebilir. Sonra cookie veya profile okunup dil değişir. Bu flash kötü kullanıcı deneyimi ve layout shift oluşturur. Server initial request'te locale'i çözebiliyorsa doğru dil doğrudan gönderilebilir. Client state başlangıç değeri server decision'ıyla eşleşmelidir.

Hydration Mismatch

Server ve client farklı translation text üretirse framework hydration warning verebilir. Locale, time zone veya random formatted value farkı buna sebep olabilir. Deterministic formatter option'ları kullanılmalıdır. Current time render edilirse server-client timestamp farkı ayrıca düşünülmelidir. Locale provider initial context'i server'dan almalıdır.

Client ve Server Locale State Nasıl Senkronize Edilir?

Client ve server aynı locale source of truth üzerinde anlaşmalıdır. Locale-prefixed URL bu amaçla güçlü bir temel sunar. Cookie initial request selection ve preference persistence için yardımcı olabilir. Server context render sırasında locale'i taşır. Client provider navigation ve interactive translation için aynı value'yu kullanır.

URL Source of Truth

URL locale'i açık taşıdığında server ve client aynı path'i görür. Shareability ve SEO da güçlenir. Language switch URL'yi değiştirir. User profile URL üretiminde default selection sağlayabilir. URL ile provider state farklılaşırsa provider current location'dan yeniden türetilmelidir.

Cookie

Cookie URL locale bulunmadığında ilk redirect kararına yardımcı olabilir. Current locale'in tek kaynağı olarak kullanılırsa shareability azalır. Server cookie'yi request sırasında okuyabilir. Client switch preference'ı güncelleyebilir. Cookie locale prefix ile conflict ettiğinde URL daha güçlü kabul edilebilir.

Server Context

Server request-scoped locale context shared component'lere translation access sağlar. Global singleton locale concurrent request'lerde data leak riski taşır. Context immutable veya request-local olmalıdır. Backend data loader aynı locale'e erişebilir. Test her request için ayrı locale context oluşturabilmelidir.

Client Provider

Client provider interactive component'lere current locale ve translation function sunabilir. Provider initial value server render ile aynı olmalıdır. Language switch navigation üzerinden yeni provider state oluşturabilir. Büyük resource object'lerini gereksiz bütün client tree'ye taşımak bundle size artırabilir. Namespace-based loading kullanılabilir.

Locale Switch Sonrası Navigation

Switch current route'un localized equivalent'ına navigation yapmalıdır. Server yeniden render veya client transition framework'e bağlıdır. Translation resource target locale için preload edilebilir. User preference persistence async çalışabilir. Navigation preference save başarısız olsa bile kullanıcı seçimi mevcut oturumda korunmalıdır.

Multilingual URL Stratejileri

Multilingual URL tasarımı SEO, deployment ve organization structure üzerinde uzun vadeli etkiye sahiptir. Subdirectory, subdomain ve country domain modellerinin farklı trade-off'ları vardır. Query parameter public multilingual SEO için genellikle daha zayıf ve daha az anlaşılır seçenektir. Locale-specific URL user sharing ve crawler discovery'yi kolaylaştırır. Seçim market ownership ve infrastructure yeteneğine göre yapılmalıdır.

Subdirectory

Subdirectory aynı domain altında locale'i path segment olarak taşır. Deployment ve domain authority yönetimi genellikle daha basittir. /tr/ veya /de/ gibi URL'ler kullanıcı tarafından kolay anlaşılır. Server route locale segmentini parse eder. Language switch aynı resource path'in diğer prefix'ine geçebilir.

/tr/

/tr/ Türkçe content için açık URL namespace'i oluşturur. Public page'ler aynı path yapısını bu prefix altında kullanabilir. Sitemap locale URL'lerini listeleyebilir. hreflang="tr" ilgili alternate ilişkiyi tanımlayabilir. Region-specific need varsa daha spesifik tag ayrıca değerlendirilebilir.

/de/

/de/ German language version için benzer yapı sağlar. Generic German birden fazla markette ortak kullanılabilir. Market-specific content gerekiyorsa de-DE gibi locale route policy değerlendirilebilir. URL format casing ve separator açısından standardize edilmelidir. Redirect eski locale formatlarını canonical path'e taşımalıdır.

Subdomain

Subdomain locale veya market'i host seviyesinde ayırır. Infrastructure ve certificate yönetimi daha fazla operasyon getirebilir. Organization ekipleri farklı deployment ownership istiyorsa avantaj sağlayabilir. Cookie sharing ve authentication behavior ayrıca tasarlanmalıdır. SEO alternate relation yine açıkça kurulmalıdır.

de.example.com

de.example.com German variant'ı ayrı host üzerinde sunabilir. User locale değiştirince cross-subdomain navigation gerçekleşir. Session cookie domain scope doğru ayarlanmalıdır. CDN ve routing configuration her host'u tanımalıdır. Canonical ve hreflang absolute URL kullanır.

Country Domain

Country-code domain güçlü market sinyali sağlayabilir. Her country için ayrı domain operasyon ve brand yönetimi gerektirir. Aynı language farklı country site'larında kullanılabilir. Translation ve market content'i birlikte yönetmek kolaylaşabilir. Domain availability ve local legal requirement ayrıca değerlendirilmelidir.

.de

.de Germany market'i için country-code domain örneğidir. Bu yapı language değil country hedefi taşır. Site yine English veya başka language varyant sunabilir. Market ile locale ayrımının korunması burada özellikle önemlidir. Cross-domain analytics ve authentication ek teknik çalışma gerektirebilir.

Query Parameter

?lang=de teknik olarak locale seçiminde kullanılabilir. Fakat public content URL'leri için path veya domain kadar açık değildir. Canonical ve crawler discovery daha dikkatli yönetilmelidir. Internal admin tool gibi SEO gerektirmeyen ürünlerde pratik olabilir. User preference query'den kalıcı profile setting'e aktarılabilir.

Hangi Yapı Ne Zaman?

Tek ürün ve ortak infrastructure için subdirectory çoğu zaman dengeli seçenek sunar. Ayrı country organization ve güçlü market ayrımı varsa country domain değerlendirilebilir. Subdomain operasyonel ownership ayrımına yardımcı olabilir. Internal uygulamalarda query veya cookie yeterli olabilir. Karar daha sonra migration maliyeti yüksek olduğu için başlangıçta SEO ve platform ekipleriyle verilmelidir.

Çok Dilli SEO

Çok dilli SEO yalnızca translated keywords eklemek değildir. Her locale içeriğinin ayrı crawl edilebilir URL'si olmalıdır. hreflang, canonical, localized sitemap ve metadata birbiriyle uyumlu çalışmalıdır. Structured data visible localized content'i yansıtmalıdır. Otomatik browser-language redirect'i crawler'ın bütün locale URL'lerine erişimini engellememelidir.

Locale-Specific URL

Her language version unique URL kullanırsa crawler ve kullanıcı content varyantını açıkça adresleyebilir. Google da multilingual içerikte ayrı URL'leri önerir. Cookie ile aynı URL'de farklı language sunmak discovery'yi zorlaştırabilir. Locale path stable tutulmalıdır. Internal links current locale URL'lerine doğrudan bağlanmalıdır.

hreflang

hreflang aynı içeriğin farklı language veya region varyantları arasındaki ilişkiyi belirtir. Her page kendisini ve diğer karşılıklarını listelemelidir. Alternate ilişkiler karşılıklı olmalıdır. Invalid locale code annotation'ın göz ardı edilmesine yol açabilir. Sitemap veya HTML yöntemi organization'ın yönetim kolaylığına göre seçilebilir.

canonical

Canonical preferred URL hakkında search engine'e sinyal verir. Regional aynı-language varyantlarda canonical ve hreflang birlikte dikkatle kullanılmalıdır. Bütün language page'lerini tek English canonical'a yönlendirmek localized URL'lerin değerini bozabilir. Self-canonical çoğu unique translated content için doğal yaklaşımdır. URL parameter duplication ayrıca normalize edilmelidir.

Localized Sitemap

Sitemap crawler'ın locale-specific URL'leri keşfetmesine yardımcı olur. Alternate relation sitemap içinde de belirtilebilir. Çok büyük sitelerde locale veya content type bazında sitemap index kullanılabilir. Stale ve redirected URL'ler sitemap'tan temizlenmelidir. CI publish sonrası sitemap completeness kontrolü yapabilir.

Localized Metadata

Title ve meta description target language'de doğal biçimde yazılmalıdır. Kaynak metnin literal çevirisi her market için en iyi search copy olmayabilir. Marketing ve SEO localization review birlikte çalışabilir. Open Graph metadata da user sharing için locale-specific olabilir. Metadata key'leri page content lifecycle ile birlikte versionlanmalıdır.

Structured Data

Structured data page üzerinde görünen localized information ile çelişmemelidir. Product name veya offer currency gerçek content'i yansıtmalıdır. Language-specific URL structured data reference'larında doğru kullanılmalıdır. Schema vocabulary translation'a konu değildir. User-facing text field'ları locale content kaynağından gelmelidir.

hreflang Nasıl Yönetilmeli?

hreflang elle birkaç page için yazılabilir fakat büyük kurumsal site için otomasyon gerektirir. Her page locale variant set'ini content identity üzerinden bilmelidir. Self-reference ve reciprocal alternate link'ler otomatik üretilebilir. x-default neutral selector veya default page için kullanılabilir. CI broken veya eksik relation'ları publish öncesinde kontrol etmelidir.

Her Sayfanın Kendisine Referans Vermesi

Her language page'in hreflang set'i kendi URL'sini de içermelidir. Bu requirement generator tarafından otomatik uygulanabilir. Missing self-reference configuration hatası olarak raporlanmalıdır. Canonical URL ile self alternate çelişmemelidir. Dynamic routes content ID üzerinden doğru locale pair'lerini bulmalıdır.

Karşılıklı Alternate Links

A page B'yi alternate gösteriyorsa B de A'yı ilgili set içinde göstermelidir. Tek yönlü relation eksik implementation'a işaret eder. Tüm variant'lar aynı set'i paylaşmalıdır. CMS publish yalnızca bir locale'i eklediğinde relation güncellenmelidir. Automated crawler test production site üzerinde çift yönlülüğü doğrulayabilir.

Language + Region

Region-specific page varsa en-US gibi değer kullanılabilir. Sadece country code hreflang değeri olarak kullanılmaz. Generic language page en ile ayrıca sunulabilir. Locale taxonomy SEO generator ile ortak olmalıdır. Market URL ile hreflang code yanlış eşleşmemelidir.

x-default

x-default belirli language veya region'a hedeflenmeyen fallback URL'yi işaretleyebilir. Language selector page için yararlı olabilir. Bütün locale'lerin yerine kullanılmaz. Alternate set içinde diğer hreflang link'lerle birlikte bulunur. Default routing ve SEO default kavramları aynı olmak zorunda değildir.

Eksik/Bozuk hreflang Kontrolü

Broken URL veya invalid code annotation'ın değerini azaltır. CI generated page graph üzerinde validation çalıştırabilir. Production crawler redirect chain ve HTTP status kontrol edebilir. CMS locale publish edildiğinde alternate set otomatik güncellenmelidir. SEO dashboard error rate'i locale bazında gösterebilir.

Otomatik Dil Redirect'i SEO'yu Nasıl Etkiler?

Kullanıcıyı browser language'e göre zorunlu redirect etmek bütün locale URL'lerinin crawler tarafından görülmesini zorlaştırabilir. Search crawler her zaman gerçek kullanıcıyla aynı header veya location sinyalini taşımaz. Her localized URL doğrudan erişilebilir olmalıdır. Hard redirect yerine language suggestion banner bazı ürünlerde daha güvenlidir. Kullanıcının manuel seçimi her zaman otomatik tahmini geçebilmelidir.

Search Bot'ların Tüm Varyantları Görmesi

Crawler her locale variant'a normal link üzerinden ulaşabilmelidir. Locale URL'leri sitemap'ta bulunabilir. Accept-Language olmadan default page yalnızca tek varyantı gizlememelidir. Hreflang diğer sayfaları açıkça gösterir. Automatic redirect bot'un URL keşfini sınırlamamalıdır.

Kullanıcı Override

User language otomatik seçilmiş olsa bile switch ile değiştirilebilmelidir. Seçim persistence source'una kaydedilir. Sonraki ziyaret preference'ı kullanır. Redirect loop oluşmaması için explicit locale URL kontrol edilir. User override SEO bot davranışından bağımsızdır.

Hard Redirect Yerine Öneri

“Bu sayfayı Türkçe görüntülemek ister misiniz?” önerisi user agency'yi korur. Kullanıcı mevcut content'te kalabilir. Search crawler page'i doğrudan görebilir. Suggestion yalnızca supported equivalent page varsa gösterilmelidir. Dismiss tercihi session boyunca hatırlanabilir.

URL'lerin Ayrı Crawl Edilebilir Olması

Her locale URL normal 200 response ve internal link almalıdır. JavaScript click handler olmadan standard anchor üzerinden keşfedilebilir olmalıdır. Authentication gerektirmeyen public content crawler'a açık kalır. Locale switch link'leri alternate page discovery'ye de yardımcı olur. URL routing cookie dependency'sine bağlanmamalıdır.

Translation Bundle Performance

Bütün dillerin bütün mesajlarını initial JavaScript bundle'a eklemek kullanıcıların çoğuna gereksiz veri gönderir. Active locale ve gerekli namespace'leri yüklemek daha verimli modeldir. Route-level splitting navigation sırasında ihtiyaç duyulan resource'u getirir. Unused key cleanup resource boyutunu azaltır. Performance optimization caching ve network reliability ile birlikte planlanmalıdır.

Tüm Dilleri Başlangıçta Yüklememek

Kullanıcı Türkçe interface açtıysa aynı anda onlarca farklı locale resource'una ihtiyaç duymaz. Bundle build sırasında locale chunk'larına ayrılabilir. Server rendering kullanılan modelde translation client bundle'a hiç girmeyebilir. Language switch hedef locale resource'unu on-demand yükler. Offline application farklı trade-off gerektirebilir.

Aktif Locale'yi Yüklemek

Initial route yalnızca resolved locale için resource ister. Fallback language kritik namespace küçük bundle olarak tutulabilir. Locale switch öncesinde target resource prefetch edilebilir. Cache aynı locale resource'unu tekrar indirmeyi önler. Version key stale translation riskini yönetir.

Namespace Lazy Loading

Authentication ekranı billing translation'larını yüklemek zorunda değildir. Namespace route veya feature activation sırasında getirilebilir. Çok küçük yüzlerce namespace network request sayısını artırabilir. Chunk grouping gerçek feature boundary'lerine göre yapılmalıdır. Loading fallback raw key göstermemelidir.

Route Bazlı Bundle

Route manifest hangi translation namespace'lerinin gerektiğini tanımlayabilir. Router code chunk ve translation resource'u paralel yükleyebilir. Waterfall azaltmak için dependency list önceden bilinebilir. Shared common namespace cache'den gelir. Route bundle size performance budget içinde izlenebilir.

Unused Key Cleanup

Feature silindiğinde translation key'leri TMS'de kalabilir. Unused key detector source code reference'larını analiz edebilir. Dynamic key pattern detection'ı zorlaştırabileceği için sınırlanmalıdır. Deprecated key belirli release grace period sonrası temizlenebilir. Cleanup translation cost ve bundle size'ı azaltır.

Translation CDN Kullanımı

Translation CDN runtime resource dağıtımını application deployment'tan ayırabilir. Approved translation'lar edge cache üzerinden hızlı sunulur. Cache key locale, namespace ve version içermelidir. Translation publish sonrası invalidation kontrollü yapılır. Network failure durumunda bundled fallback veya stale-safe cache stratejisi kullanıcı deneyimini koruyabilir.

Runtime Translation Loading

Application gerekli resource'u runtime'da HTTP üzerinden alabilir. Bu model translation'ın code deploy olmadan güncellenmesini sağlar. İlk render latency'si network dependency kazanır. Critical namespace server-side preload edilebilir. Security için resource origin ve integrity politikası değerlendirilmelidir.

Edge Cache

Edge cache translation JSON'u kullanıcıya yakın lokasyonda sunabilir. Resource çoğunlukla read-heavy olduğu için yüksek cacheability sağlar. Versioned immutable URL uzun TTL kullanabilir. Latest alias kısa TTL veya explicit invalidation gerektirebilir. Metrics edge hit ratio'yu izleyebilir.

Cache Key'de Locale

tr ile de resource aynı cache entry'yi paylaşmamalıdır. Locale path veya query key içinde açıkça bulunmalıdır. Namespace ve translation version da key'in parçası olabilir. CDN Vary header üzerinden Accept-Language cache etmek yerine explicit URL çoğu zaman daha predictable olur. Debugging hangi artifact'ın geldiğini kolaylaştırır.

Translation Version

Translation publish için immutable version identifier kullanılabilir. Application release belirli minimum version ile çalışabilir. Rollback eski resource'a hızlı dönüş sağlar. TMS approval set'i version tag oluşturabilir. Monitoring error event'ine version eklenmesi root cause analizini kolaylaştırır.

Cache Invalidation

Mutable URL kullanılıyorsa approved translation değişikliği cache invalidation gerektirir. Global purge yüksek maliyetli olabilir. Locale ve namespace scoped purge daha güvenlidir. Immutable versioned URL invalidation ihtiyacını büyük ölçüde azaltır. Client manifest latest version'ı kontrollü biçimde öğrenebilir.

Build-Time mı Runtime Translation mı?

Build-time ve runtime translation modellerinin farklı operasyon avantajları vardır. Build-time resource application artifact'ıyla aynı version içinde güvenli ve hızlı dağıtılır. Runtime model translation'ın kod deploy edilmeden değişmesini sağlar. Hybrid yaklaşım kritik bundle'ları build içinde, sık değişen content'i CDN üzerinden sunabilir. Seçim release cadence, offline requirement ve governance ihtiyacına göre yapılmalıdır.

Build-Time Bundle

Translation dosyaları build sırasında JavaScript veya server artifact'ına dahil edilir. Application ve message version arasında mismatch riski düşüktür. Yeni translation için yeniden deploy gerekir. Çok fazla locale artifact size'ını büyütebilir. Locale-specific build veya code split bu yükü azaltabilir.

Runtime API

Runtime API translation resource'u deployment sonrası sunar. Localization ekibi approved copy'yi bağımsız yayınlayabilir. Network ve cache failure yeni risk alanları oluşturur. Contract versioning key schema ile uyumlu olmalıdır. Critical legal string için publish approval daha sıkı olabilir.

Hybrid Model

Hybrid model common ve critical messages'ı build artifact içinde tutabilir. Daha büyük feature namespace'leri runtime yüklenebilir. Offline veya initial render safety böylece korunur. Language switch resource CDN'den tamamlanabilir. İki source arasındaki precedence açıkça tanımlanmalıdır.

Deployment Bağımlılığı

Build-time model translation correction'ını application deployment süresine bağlar. Bu bazı regulated ürünlerde audit açısından avantaj olabilir. Hızlı content düzeltmesi gereken ürünlerde yavaş kalabilir. Runtime model dependency'yi azaltır fakat ayrı release governance gerektirir. Organization mevcut deployment maturity'sine göre seçim yapmalıdır.

Translation'ın Kod Deploy Olmadan Güncellenmesi

Runtime publishing typo veya terminology fix'ini hızlı yapmayı sağlar. Key schema değişmedikçe application source değişmez. Approved translation CDN'e yeni version olarak çıkar. Rollback tek translation version değiştirilerek yapılabilir. Legal content için yine formal approval zorunlu tutulabilir.

Translation Management System (TMS) Nedir?

TMS localization operasyonunu tek platformda yöneten sistem kategorisidir. Translator workspace, translation memory, glossary, review ve versioning sağlar. API veya CLI developer pipeline ile entegrasyon kurar. Screenshot ve context mesajla birlikte taşınabilir. Kurumsal seçimde security, data residency ve audit yetenekleri de translation özellikleri kadar önemlidir.

Translator Workspace

Translator source ve target mesajları düzenleyebileceği özel arayüz kullanır. Code repository bilgisine ihtiyaç duymaz. Placeholder'lar korumalı token olarak gösterilebilir. Screenshot veya preview context'i aynı ekranda bulunabilir. Review status workflow içinde izlenebilir.

Translation Memory

Translation memory daha önce çevrilmiş segmentleri tekrar önerir. Aynı product terminology tutarlı kalır. Benzer source değişikliklerinde fuzzy match maliyeti azaltabilir. Eski yanlış translation da yeniden önerilebileceği için review önemlidir. Memory version veya domain bazında yönetilebilir.

Glossary

Glossary approved product ve domain terminology'yi tanımlar. Belirli kelimelerin her locale'de nasıl çevrileceği veya çevrilmeyeceği belirtilir. Translator otomatik warning alabilir. Marketing ve legal termbase ayrı ownership taşıyabilir. Glossary change de versioned review gerektirebilir.

Context

Key tek başına her zaman yeterli translation context sağlamaz. Description, screenshot ve component name TMS'e taşınabilir. Placeholder örnek değerleri eklenebilir. Kullanıldığı user journey açıklanabilir. Context kalitesi linguistic defect oranını doğrudan etkileyebilir.

Review

Translation tamamlandıktan sonra second reviewer approval aşaması uygulanabilir. Tier 1 locale'lerde zorunlu olabilir. Legal content specialist approval gerektirir. Review rejection reason translator'a geri dönmelidir. Approved status production publish için gate olur.

API/CLI

API veya CLI source key sync işlemini otomatikleştirir. CI yeni key'leri TMS'e gönderir. Approved target resource build veya runtime publish için alınır. Token least-privilege permission taşımalıdır. Pipeline retry ve rate limit davranışı kontrollü olmalıdır.

Versioning

TMS translation set'lerini release veya snapshot olarak versionlayabilir. Application belirli approved version'ı kullanır. Hotfix yeni patch translation version oluşturabilir. Rollback eski snapshot'a döner. Audit kimin hangi metni ne zaman değiştirdiğini gösterebilmelidir.

Continuous Localization Workflow

Continuous localization çeviri işini development tamamlandıktan sonra yapılan toplu faaliyet olmaktan çıkarır. Developer key eklediğinde CI bunu otomatik olarak TMS'e gönderir. Translation ve review feature geliştirmeyle paralel ilerleyebilir. Approved resource staging'e yayınlanır ve QA yapılır. Böylece yüksek release hızında localization sürekli yetişmeye çalışan manuel süreç olmaktan çıkar.

Developer Yeni Key Ekler

Developer semantic key ve source message ekler. Description ve placeholder metadata mümkünse aynı commit'te bulunur. Local test message syntax'ını doğrular. Pull request reviewer key naming standardını kontrol eder. Merge sonrasında pipeline yeni key'i tespit eder.

CI Key'i TMS'e Gönderir

CI source catalog diff'ini çıkarır. Yeni veya değişmiş key TMS API'sine gönderilir. Deleted key hemen silinmek yerine deprecated status alabilir. Sync sonucu build metadata'ya yazılır. API failure source code merge'ini organization policy'sine göre bloklayabilir.

Translation Başlar

TMS target locale assignment'larını oluşturur. Translation memory ve glossary önerileri sunulur. AI draft izin verilen içeriklerde başlangıç sağlayabilir. Translator context ve screenshot'a erişir. Due date feature release planıyla ilişkilendirilebilir.

Review Yapılır

Second reviewer linguistic doğruluk ve terminology kontrolü yapar. Critical content domain specialist'e gider. Placeholder ve syntax otomatik validator'dan geçer. Rejected item translator'a açıklamayla geri döner. Approval production readiness'in resmi sinyalidir.

Approved Translation Release Edilir

Approved message'lar belirli translation release içine alınır. Locale completeness threshold kontrol edilir. Version tag oluşturulur. Artifact staging veya CDN'e publish edilir. Production promotion ayrı onay gerektirebilir.

Application Translation'ı Yükler

Build-time model artifact'ı compile sırasında alır. Runtime model manifest üzerinden approved version'ı yükler. Cache locale ve version'a göre çalışır. Missing resource fallback policy devreye girer. Telemetry gerçek production kullanımını ölçer.

Translation Memory Nedir?

Translation memory geçmiş source-target segment çiftlerini saklayarak gelecekte yeniden kullanım sağlar. Aynı veya benzer cümle geldiğinde translator'a öneri sunar. Bu yöntem tutarlılığı ve hızı artırabilir. Ancak eski context'te doğru olan translation yeni context'te yanlış olabilir. Memory önerisi human review yerine geçmemelidir.

Daha Önce Çevrilmiş Segmentleri Yeniden Kullanmak

Aynı button veya açıklama tekrarlandığında translation memory mevcut target'ı önerir. Translator sıfırdan yazmak zorunda kalmaz. Exact match yüksek confidence sağlayabilir. Context değiştiğinde yine kontrol gerekir. Duplicate source segment farklı domain meaning taşıyabilir.

Tutarlılık

Product terminology tekrar tekrar aynı biçimde çevrilebilir. Translation memory bu consistency'yi destekler. Glossary ile birlikte kullanıldığında approved term'ler korunur. Farklı translator'ların style farkı azalır. Tutarlılık kullanıcıların feature kavramlarını daha hızlı öğrenmesine yardımcı olur.

Maliyet

Reused segmentler translation maliyetini azaltabilir. Fuzzy match partially changed sentence için başlangıç sağlar. Pricing model vendor veya TMS'e göre değişebilir. Savings yalnızca kelime sayısıyla değil review süresiyle de ölçülmelidir. Poor memory quality tasarrufu tersine çevirebilir.

Eski Translation Memory'nin Hatalı İçeriği Yayması

Yanlış approved translation memory'ye girdiyse yeni segmentlerde sürekli önerilebilir. Terminology değişikliği eski memory'yi stale hale getirebilir. Governance outdated entry'leri invalidate edebilmelidir. Reviewer suggestion source'unu görebilmelidir. Quality audit en çok reused segmentleri de örneklemelidir.

Glossary ve Termbase

Glossary product ve domain terminology'sinin locale'ler arasında tutarlı kullanılmasını sağlar. Marka isimleri, feature adları ve teknik terimler için approved karşılıklar belirlenebilir. Do-not-translate list özel isimlerin yanlış çevrilmesini engeller. Terminology ownership product, marketing veya legal ekipleri arasında paylaşılabilir. TMS translator'a glossary ihlalini çalışma sırasında gösterebilir.

Product Terminology

Product içinde aynı kavrama farklı ekranlarda farklı isim verilmemelidir. Source terminology standardı translation kalitesinin temelidir. Feature rename bütün locale glossary'sini etkiler. Approved term screenshot ve context ile açıklanabilir. Product manager terminology owner rolü üstlenebilir.

Domain Terminology

Finans, lojistik veya sağlık gibi domain'lerde uzman terminology gerekir. Genel translator literal karşılıkla yanlış anlam üretebilir. Subject-matter reviewer kritik term'leri onaylamalıdır. Glossary definition kavramın anlamını açıklar. High-risk content human review'dan geçmelidir.

Do-Not-Translate List

Marka, product name veya protocol term'i çevrilmeden kalabilir. Bu değerler do-not-translate list içinde tutulur. Script transliteration gerekiyorsa locale-specific policy belirlenebilir. Translator tool warning verebilir. List sürekli brand guideline ile senkron tutulmalıdır.

Approved Terminology

Bir concept için birkaç doğru translation olsa bile ürün tek preferred term seçebilir. Approved terminology kullanıcı eğitimini kolaylaştırır. Support documentation aynı term'leri kullanır. Search ve help center query'leri daha tutarlı olur. Değişiklik migration ve user communication gerektirebilir.

Kurumsal Dil Tutarlılığı

Kurumsal dil yalnızca grammar doğruluğu değil tone ve terminology consistency'sidir. TMS glossary, style guide ve reviewer bunu birlikte korur. Marketing copy daha esnek tone kullanırken admin UI daha doğrudan olabilir. Locale-specific style guide bu farkları açıklar. Quality metric terminology defect oranını ayrıca izleyebilir.

Translator'a Context Nasıl Sağlanmalı?

Translator source string'in kullanıldığı yeri bilmiyorsa doğru translation üretmek zorlaşır. Screenshot, component adı ve açıklama context sağlar. Character limit gerçek UI kısıtı varsa belirtilmelidir. Placeholder'ın neyi temsil ettiği ve örnek value yazılmalıdır. User journey bilgisi özellikle kısa ve ambiguous string'lerde büyük fark yaratır.

Screenshot

Screenshot message'ın ekrandaki konumunu gösterir. Translator bunun title, button veya error olduğunu görür. Surrounding text grammar kararına yardımcı olur. Automated screenshot capture key ile TMS'e bağlanabilir. Screenshot stale olduğunda version bilgisiyle yenilenmelidir.

Component

Component metadata string'in hangi UI primitive'inde kullanıldığını belirtir. Button label ile table header aynı source word için farklı translation gerektirebilir. Component name developer terminology'si translator'a tek başına yeterli olmayabilir. Description ile birlikte sunulmalıdır. Reusable component birçok journey'de kullanılıyorsa bu da belirtilmelidir.

Description

Description mesajın anlamını açık cümleyle anlatır. “Shown when payment authorization fails” gibi açıklama key'den daha değerlidir. Translator target user ve tone'u anlayabilir. Description source code comment'ten otomatik alınabilir. Copy değiştiğinde description doğruluğu review edilmelidir.

Character Limit

SMS veya compact button gerçek character kısıtı taşıyabilir. Translator bu bilgiyi önceden bilirse uygun kısa ifade seçebilir. Limit sadece design fixed width probleminden kaynaklanıyorsa component'i düzeltmek daha doğru olabilir. Hard limit metadata içinde unit'iyle belirtilmelidir. TMS target length warning verebilir.

Placeholder Açıklaması

{name} bir kişi mi organization mı olduğu translator için önemli olabilir. Placeholder example value verilmelidir. Gender veya number behavior varsa açıklanmalıdır. Translator token'ı değiştirmemelidir. CI placeholder identity'yi otomatik korur.

Kullanıldığı User Journey

Checkout warning ile onboarding hint aynı tone'u kullanmayabilir. Journey bilgisi translator'a mesajın önem seviyesini gösterir. Legal veya destructive action content özel review alabilir. Screenshot tek ekranı gösterirken journey daha geniş context sağlar. TMS feature tag'leri bu metadata için kullanılabilir.

AI ve Machine Translation Kurumsal i18n'de Nasıl Kullanılmalı?

Machine translation düşük riskli içerik için ilk taslak üretimini hızlandırabilir. Bununla birlikte product terminology, legal anlam ve UI context hataları human review gerektirir. Risk seviyesi content type'a göre sınıflandırılmalıdır. Context-aware prompt veya glossary kullanımı output kalitesini artırabilir. Production publish öncesinde açık kalite kapısı korunmalıdır.

First Draft

AI translation translator'a başlangıç metni sağlayabilir. Source description ve glossary input olarak verilebilir. Translator yalnızca proofread değil anlam ve tone review yapmalıdır. Draft status TMS içinde approved translation'dan ayrı tutulmalıdır. Machine output doğrudan production artifact'a geçmemelidir.

Human Review

Human reviewer grammar, terminology ve product context'i değerlendirir. Critical market copy native reviewer gerektirebilir. Reviewer machine suggestion'a aşırı güvenmemelidir. Quality sampling model veya prompt değiştiğinde artırılabilir. Approval audit trail içinde kaydedilir.

Low-Risk Content

Internal admin hint veya düşük etkili help text machine-assisted workflow için uygun olabilir. User harm ihtimali düşük olmalıdır. Yine de terminology validator çalıştırılmalıdır. Locale tier'a göre human sampling uygulanabilir. Production feedback yanlış translation'ı hızlı düzeltmeye yardımcı olur.

High-Risk Content

Legal, payment, security ve safety content machine-only translation'a bırakılmamalıdır. Domain specialist review gerekebilir. Source content de açık ve approved olmalıdır. Translation version market ve legal approval ile bağlanır. Automated publish gate bu content class'ında kapatılabilir.

Context-Aware Prompting

Source string tek başına machine model için ambiguous olabilir. Component, screenshot description ve glossary context olarak sağlanabilir. PII prompt'a gönderilmemelidir. Prompt template versionlanabilir. Quality metric prompt veya model version bazında karşılaştırılabilir.

Quality Gate

Machine output syntax, placeholder ve glossary validator'dan geçmelidir. Human approval gereken content otomatik olarak review queue'ya gider. Linguistic score tek başına production release kararı olmamalıdır. Risk-based threshold kullanılabilir. Audit hangi translation'ın machine-assisted olduğunu gösterebilir.

Hangi İçerikler Tam Otomatik Çevrilmemeli?

Yüksek etki veya yanlış anlaşılma riski taşıyan içerikler insan review'u olmadan yayınlanmamalıdır. Legal, payment, security ve safety mesajları bu gruba girer. Healthcare veya başka high-stakes içerik uzman kontrolü gerektirir. Brand-critical campaign copy tone açısından ayrıca review edilmelidir. Automation yardımcı araç olabilir fakat accountability insan ve kurum süreçlerinde kalmalıdır.

Legal

Legal copy küçük bir anlam farkında bile farklı sonuç doğurabilir. Qualified reviewer target language metnini onaylamalıdır. Market-specific version ayrıca kontrol edilir. Translation memory suggestion doğrudan kabul edilmemelidir. Effective date ve approval metadata tutulmalıdır.

Payment

Payment disclosure kullanıcıdan para ile ilgili karar ister. Fee, renewal veya refund ifadesi doğru anlaşılmalıdır. Currency value machine-generated formatter'dan gelir. Human reviewer terminology ve sentence meaning'i doğrular. Checkout visual QA text'in kesilmediğini kontrol eder.

Security

Security warning kullanıcı davranışını doğru yönlendirmelidir. Ambiguous translation phishing benzeri yanlış anlam oluşturabilir. Approved terminology tutarlı kullanılmalıdır. Link destination ve security action copy birlikte review edilir. Emergency update workflow hızlı human approval sağlayabilmelidir.

Safety

Safety instruction yanlış çevrildiğinde kullanıcı zararı oluşabilir. Domain uzmanı linguistic reviewer ile birlikte çalışmalıdır. Translation fallback başka language'e otomatik düşmemelidir. Release completeness zorunlu olabilir. Visual presentation warning'ın görünürlüğünü korumalıdır.

Healthcare/High-Stakes İçerik

High-stakes health content uzman incelemesi gerektirir. Machine draft yalnızca destekleyici olabilir. Clinical terminology locale-specific standarda uymalıdır. User-generated veya unverified translation authoritative content gibi gösterilmemelidir. Compliance ve legal ekipleri market requirement'ını ayrıca değerlendirir.

Brand-Critical Copy

Campaign slogan veya product positioning literal translation ile doğal olmayabilir. Marketing transcreation yaklaşımı gerekebilir. Brand voice target culture'a uygun biçimde uyarlanır. Legal trademark ve claim kontrolü yapılabilir. Final content locale marketing owner tarafından onaylanır.

Translation Workflow'da Güvenlik

TMS ve translation CDN product content supply chain'inin parçasıdır. Yetkisiz kişi bir string'i değiştirirse phishing veya yanlış yönlendirme içeriği production'a girebilir. SSO, RBAC ve least privilege access bu nedenle önemlidir. API token'ları secret management sistemi içinde tutulmalıdır. Audit log bütün critical publish işlemlerini izlenebilir hale getirir.

SSO

SSO kurum kimlik yönetimini translation platformuna bağlar. Çalışan ayrıldığında access merkezi olarak kaldırılabilir. MFA policy organization standardıyla uygulanabilir. External translator için federation veya controlled guest account kullanılabilir. Shared password account kullanılmamalıdır.

RBAC

Role-based access control translator, reviewer ve publisher yetkilerini ayırır. Translator production publish yapamamalıdır. Legal reviewer yalnızca ilgili project'e erişebilir. Admin role sınırlı sayıda kişide tutulur. Permission audit düzenli yapılmalıdır.

Least Privilege

Her kullanıcı yalnızca işini yapmak için gereken locale ve project'e erişmelidir. External vendor bütün organization content'ini görmek zorunda değildir. API token da yalnızca sync endpoint permission'ı taşımalıdır. Geçici project erişimi expiration ile verilebilir. Access review offboarding sürecinin parçasıdır.

Audit Log

Kim hangi translation'ı ne zaman değiştirdiği kaydedilmelidir. Approval ve production publish action'ları ayrıca görünür olmalıdır. Legal string history audit için kritik olabilir. Log değiştirilemez veya yeterli retention'a sahip olmalıdır. Incident response belirli kötü değişikliği hızlıca bulabilir.

API Token

CI integration token'ı repository içine yazılmamalıdır. Secret manager üzerinden inject edilmelidir. Read ve write token ayrılabilir. Rotation policy düzenli uygulanır. Loglarda token value maskelenmelidir.

Encryption

Translation content transit sırasında TLS ile korunmalıdır. Sensitive unpublished product copy at-rest encryption requirement'ına girebilir. Key management vendor security review kapsamında değerlendirilmelidir. Encryption PII'nin TMS'e gönderilmesi için tek başına yeterli gerekçe değildir. Data minimization öncelikli kalmalıdır.

PII ve Translation Vendor Riski

Translation sistemi gerçek kullanıcı verisi işlemek zorunda değildir. Source message örneklerinde gerçek isim, e-mail veya account bilgisi kullanılmamalıdır. Screenshot context PII içerebileceği için redaction uygulanmalıdır. Vendor data residency ve subprocessor politikası procurement sürecinde değerlendirilmelidir. Tokenization gerçek value yerine güvenli placeholder kullanmayı sağlar.

Kullanıcı Verisini Translation Sistemine Göndermemek

Translation key Hello {name} şeklinde tutulabilir ve gerçek name runtime'da eklenir. TMS'e gerçek user record göndermek gereksizdir. Screenshot automated capture synthetic account kullanabilir. Log ve bug report PII maskeler. Data minimization vendor breach impact'ini azaltır.

Redaction

Screenshot veya source context hassas bilgi içeriyorsa redaction uygulanmalıdır. Automated capture test data kullanarak riski daha baştan azaltabilir. Redaction reversible olmamalıdır. Reviewer context'i kaybetmeyecek kadar açıklama bırakılmalıdır. Process legal ve security policy ile uyumlu olmalıdır.

Tokenization

Gerçek value yerine {customerName} gibi token kullanılır. Translator variable type ve örnek synthetic value görür. Runtime actual value güvenli environment'da yerleştirilir. Token format CI tarafından korunur. Bu yaklaşım placeholder design ile privacy hedefini birleştirir.

Data Residency

Bazı kurumlar translation content'inin belirli bölgede saklanmasını isteyebilir. Vendor hosting region ve backup location incelenmelidir. Legal string PII olmasa bile confidential product information taşıyabilir. Data processing agreement requirement procurement ile değerlendirilir. Architecture gerektiğinde regional TMS project ayrımı destekleyebilir.

Subprocessor Yönetimi

Translation vendor başka model veya service provider kullanabilir. Subprocessor listesi security review'da incelenmelidir. Machine translation özelliği content'i üçüncü tarafa gönderebilir. Opt-out veya private model seçeneği değerlendirilebilir. Contract değişiklik bildirimi organization policy'sine uygun olmalıdır.

Legal String Governance

Legal string normal UI copy'den ayrı lifecycle gerektirir. Version, approval ve effective date translation ile birlikte tutulmalıdır. Market ve locale selection birlikte yapılabilir. Audit trail kullanıcıya hangi version'ın gösterildiğini kanıtlayabilmelidir. Generic fallback legal content için default olarak kapalı olmalıdır.

Legal Metni Normal UI String'i Gibi Yönetmemek

Normal button copy hızlıca güncellenebilir. Legal text ise onay ve record retention gerektirebilir. Ayrı namespace veya content service kullanılabilir. Publishing permission yalnızca legal-approved role'a verilebilir. Translation TMS'de olsa bile final activation application config üzerinden kontrol edilebilir.

Version

Her legal document immutable version identifier taşımalıdır. Translation aynı source version ile ilişkilendirilir. Source değişince eski target otomatik valid kabul edilmemelidir. User acceptance version ID ile kaydedilir. Rollback historical content'i yeniden gösterebilir.

Legal Approval

Locale legal reviewer approval olmadan publish olmamalıdır. Approval user identity ve timestamp ile kaydedilir. Source ve target diff reviewer'a gösterilebilir. Machine translation draft yalnızca başlangıç olabilir. Emergency fix süreci de audit'i korumalıdır.

Effective Date

Legal content belirli tarihten itibaren geçerli olabilir. Scheduling service locale variant'ları aynı anda veya market-specific tarihte aktive edebilir. User'a effective date localized formatta gösterilir. Stored date machine representation olarak kalır. Time zone activation policy açıkça belirlenmelidir.

Locale/Market Bazlı Metin

Aynı language farklı jurisdiction için farklı metin gerektirebilir. Content key language değil locale plus market dimension kullanabilir. Fallback yalnızca legal owner tarafından izin verilen kombinasyonlarda çalışır. Unsupported market transaction'ı engelleyebilir. Test matrix bütün active market-locale pair'lerini kapsamalıdır.

Audit Trail

Source edit, translation edit, approval ve publish event'leri kaydedilmelidir. User acceptance hangi version'a karşılık geldiğiyle birlikte tutulur. Audit log retention policy legal requirement'a göre belirlenir. Data access least privilege ile korunur. Incident sırasında historical state yeniden oluşturulabilmelidir.

Multi-Tenant Localization

Multi-tenant ürünlerde global translation set'i bütün müşteriler için temel sağlar. Bazı enterprise tenant'lar terminology veya white-label copy override etmek isteyebilir. Override precedence açıkça tanımlanmalıdır. Tenant translation base message değiştiğinde stale hale gelebilir. Cache key tenant, locale ve translation version bilgilerini gerektiğinde içermelidir.

Ortak Base Translation

Base translation product ekibinin onaylı terminology'sini taşır. Yeni tenant hiçbir override yapmadan tam locale experience alabilir. Base key bütün müşteri customizations için fallback sağlar. Product copy değişikliği bütün tenant'ları etkileyebilir. Breaking terminology change override audit'i tetiklemelidir.

Tenant Override

Tenant belirli key için kendi approved text'ini tanımlayabilir. Override yalnızca allowlist key'lerde desteklenebilir. Security veya legal message override'a kapalı tutulabilir. Admin UI preview ve locale selection sağlamalıdır. Değişiklik audit log'a yazılmalıdır.

Customer Terminology

Bazı müşteriler “employee” yerine kendi internal term'ini kullanmak isteyebilir. Tenant glossary tekrar eden override'ı merkezi tanımlar. Grammar nedeniyle yalnızca kelime replace yapmak her dilde güvenli değildir. Message-level override veya terminology-aware translation gerekebilir. Customer-specific term native reviewer tarafından kontrol edilmelidir.

White-Label Product

White-label ürün brand name ve bazı UI copy alanlarında daha geniş customization gerektirebilir. Base component ve translation system tenant theme ile birlikte çalışmalıdır. Logo translation key olmamalıdır. Tenant-specific legal ownership ayrıca tanımlanmalıdır. Preview environment müşteri locale ve brand kombinasyonunu gösterebilmelidir.

Override Precedence

Resolution örneğin tenant-locale override, locale base ve global default şeklinde çalışabilir. Bu sıra bütün services tarafından aynı uygulanmalıdır. Debug panel final message'ın hangi katmandan geldiğini gösterebilir. Hidden precedence rules support süresini artırır. Config testleri override chain'i sabitler.

Tenant-Specific Translation Resolution

Tenant-specific translation resolver normal locale fallback'e ek bir customization katmanı ekler. Önce exact tenant ve locale override kontrol edilebilir. Sonra product locale base translation'a düşülür. Global default en son kullanıcı-facing fallback olur. Resolver result source metadata monitoring ve admin preview için saklanabilir.

Tenant + Locale Override

En spesifik değer tenant ve exact locale kombinasyonudur. Bu override customer terminology'nin hedef language biçimini taşır. Base source version ile association stale detection sağlar. Missing override normal durumdur ve error değildir. Permission yalnızca tenant admin veya approved role'a verilebilir.

Locale Base Translation

Tenant override yoksa product'ın onaylı locale translation'ı kullanılır. Bu katman normal kullanıcıların gördüğü standard copy'dir. Quality SLA locale tier'a göre uygulanır. Base update tüm tenant fallback'lerini etkiler. Change log customer admin'e gerekli olduğunda gösterilebilir.

Global Default

Locale translation da yoksa global default yalnızca izin verilen message class'larında kullanılabilir. Mixed-language experience telemetry üretir. Critical tenant contract locale'inde fallback release blocker olabilir. Default language configuration merkezi olmalıdır. Raw key production fallback olarak kullanılmamalıdır.

Missing Override

Tenant'ın her key'i override etmesi beklenmez. Missing override base translation kullanır. Admin UI yalnızca değiştirilmiş key'leri gösterebilir. Search base ve override value'ları karşılaştırabilir. Override reset işlemi custom row'u silerek base behavior'a dönebilir.

Cache Strategy

Tenant-aware resource cache cross-tenant data leak riskine dikkat etmelidir. Cache key tenant ID, locale ve version içerebilir. Base translation ayrı shared cache'te tutulabilir. Override delta küçük payload olarak merge edilebilir. Invalidation yalnızca ilgili tenant ve locale'i etkilemelidir.

Translation Override'lar Nasıl Güncel Tutulur?

Base source string değiştiğinde eski tenant override semantic olarak hâlâ uygun olmayabilir. Override source version ile ilişkilendirilirse stale durum otomatik tespit edilebilir. Diff admin'e hangi source copy'nin değiştiğini gösterir. Review required state override'ın production'da kullanılmaya devam edip etmeyeceğini policy'ye göre belirler. Tenant admin notification kritik değişiklikleri görünür hale getirir.

Base String Değişince Stale Override

Product “Download invoice” mesajını daha açıklayıcı biçimde değiştirirse tenant'ın eski custom text'i yeni intent'i karşılamayabilir. Sistem override'ı stale olarak işaretleyebilir. Automatic fallback veya keep-current policy content riskine göre seçilir. Legal message için stale override kabul edilmemelidir. Review dashboard öncelikli item'ları listeler.

Override Version

Override hangi base key version üzerinden oluşturulduğunu saklayabilir. Base version değiştiğinde mismatch kolayca bulunur. Tenant edit yeni version'a rebase edilir. Historical override audit için saklanabilir. Version internal monotonic ID veya content hash olabilir.

Diff

Admin source old ve new text diff'ini görebilir. Placeholder değişikliği özellikle vurgulanmalıdır. New placeholder override içinde eksikse publish engellenir. Terminology change açıklaması release note olarak eklenebilir. Diff review süresini kısaltır.

Review Required

Stale override otomatik review_required status alabilir. Low-risk copy belirli süre eski haliyle kullanılabilir. High-risk content hemen base fallback veya block behavior gerektirebilir. Review role tenant governance'e göre belirlenir. Status monitoring uzun süre çözülmeyen override'ları gösterir.

Tenant Admin Notification

Product update tenant customization'ını etkiliyorsa admin bilgilendirilebilir. Notification yalnızca gerçekten action gereken durumda gönderilmelidir. Link doğrudan affected translation review ekranına gidebilir. E-mail kendisi admin locale'inde localized olur. Notification delivery audit edilebilir.

i18n Test Stratejisi

i18n testleri yalnızca translation function'ın string döndürdüğünü kontrol etmekle sınırlı kalmamalıdır. Unit test formatter ve locale resolver gibi deterministic logic'i doğrular. Integration test routing ve resource loading'i birlikte çalıştırır. E2E gerçek language switch ve user journey behavior'ını test eder. Visual ve linguistic QA ise code testlerinin kapsamadığı metin ve layout kalitesini tamamlar.

Unit Tests

Locale resolver priority chain unit test için uygundur. Formatter belirli locale ve time zone ile deterministic output verebilir. Translation key parser invalid ICU syntax'ı test edebilir. Tenant override resolver fallback sırasını doğrulayabilir. Test environment process default locale'e güvenmemelidir.

Integration Tests

Route locale değiştiğinde doğru resource bundle'ın yüklendiği test edilebilir. Backend request locale header ile doğru notification template seçebilir. TMS artifact fixture gerçek file schema'sını kullanabilir. Missing namespace fallback behavior doğrulanır. Server-client hydration aynı locale ile çalışmalıdır.

E2E Tests

Kullanıcı language switcher ile locale değiştirir. URL ve UI text birlikte güncellenmelidir. Refresh preference'ı korumalıdır. Direct localized URL doğru page'i açmalıdır. Critical checkout veya auth journey Tier 1 locale'lerde E2E coverage alabilir.

Visual Regression

Screenshot test text expansion ve RTL layout değişikliklerini yakalar. Locale başına bütün uygulamayı test etmek maliyetli olabilir. Critical component ve route set'i seçilebilir. Pseudo-locale çok sayıda problemi gerçek translation olmadan ortaya çıkarır. Baseline update review bilinçli yapılmalıdır.

Linguistic QA

Linguistic QA grammar, terminology ve naturalness değerlendirir. Native veya uzman reviewer gerçek product context içinde çalışır. Screenshot review metni uygulama içinde görmeyi sağlar. Defect severity user impact'e göre sınıflandırılır. Findings glossary ve source copy iyileştirmesine geri beslenir.

Pseudo-Localization Nedir?

Pseudo-localization gerçek translation üretmeden source message'ı yapay bir locale'e dönüştüren test tekniğidir. Metin uzatılabilir ve accent karakterleri eklenebilir. Hard-coded source string değişmediği için kolayca fark edilir. Font ve layout sorunları translation ekibi çalışmaya başlamadan bulunabilir. CI veya component preview ortamında pseudo-locale sürekli erişilebilir tutulabilir.

Metni Yapay Olarak Uzatmak

Pseudo message source text'i belirli yüzde oranında uzatabilir. Bu behavior button ve table overflow problemlerini ortaya çıkarır. Placeholder value'lar bozulmadan korunmalıdır. Çok aşırı uzatma gerçekçi olmayan noise oluşturabilir. Project target locale'lerine göre reasonable expansion ratio seçilebilir.

Accent Karakterleri

Latin source harflerini accented benzerleriyle değiştirmek font ve encoding coverage'ı test eder. Developer translated olmayan hard-coded string'i normal English olarak hemen fark eder. Placeholder ve HTML token'ları transform edilmemelidir. Screen reader test pseudo text için meaningful değildir. Ama visual infrastructure açısından oldukça faydalıdır.

Hard-Coded String Yakalamak

Pseudo locale aktifken resource'tan gelen bütün mesajlar dönüştürülür. Ekranda normal source language kalan text hard-coded olabilir. QA bu noktaları kolayca bulur. Automated screenshot OCR kullanmaya gerek olmadan visual review yeterli olabilir. Lint ile birlikte iki katmanlı detection sağlar.

Font Sorunlarını Görmek

Accented character'lar primary font'un extended glyph coverage'ını test eder. Missing glyph fallback ile farklı font görünebilir. Line-height veya baseline problemi ortaya çıkabilir. Gerçek CJK ve Arabic font sorunları için ayrıca script-specific story gerekir. Pseudo-locale yalnızca erken genel sinyal sağlar.

Translation Gelmeden Önce i18n QA Yapmak

Feature development sırasında target translation henüz hazır olmayabilir. Pseudo-locale layout ve key extraction testini yine mümkün kılar. Developer pull request preview'da pseudo mode açabilir. Localization ekiplerinin son anda UI bug bulma yükü azalır. Böylece engineering readiness translation readiness'den önce doğrulanabilir.

Pseudo-RTL Testi

Pseudo-RTL gerçek Arabic translation beklemeden application direction'ını sağdan sola çevirir. Layout mirror davranışı ve logical CSS usage hızlı biçimde test edilir. Directional icon'lar gözden geçirilir. Source text aynı language'de kalabilir fakat direction environment RTL olur. Bu test linguistic QA'nın yerine geçmez, yalnızca engineering readiness sağlar.

Layout'u Mirror Etmek

Root dir RTL yapıldığında flex ve logical properties beklenen şekilde davranmalıdır. Hard-coded left margin problemleri görünür olur. Sidebar ve navigation order design spec'e göre kontrol edilir. Modal ve dropdown positioning ayrıca test edilir. Screenshot compare hızlı feedback sağlar.

Logical CSS Testi

Pseudo-RTL fiziksel property bağımlılıklarını ortaya çıkarır. margin-left gerektiği gibi mirror olmuyorsa component review edilir. Logical property'ye geçiş mümkünse yapılır. Gerçek physical direction taşıyan öğeler istisna olarak belgelenir. CSS lint directional rule kullanımını destekleyebilir.

Directional Icon Testi

Back arrow ve breadcrumb separator mirror olmalıdır. Logo ve clock icon aynı kalmalıdır. Pseudo environment icon metadata hatalarını hızlı gösterir. Screenshot automated comparison kullanılabilir. Icon library directional flag testleri unit seviyesinde de yapılabilir.

RTL Dil Çevirisi Beklemeden Hata Bulmak

Engineering team locale translation hazır olmadan RTL support geliştirebilir. Bu parallel work release süresini kısaltır. Actual Arabic QA daha sonra typography ve linguistic behavior'ı doğrular. Pseudo-RTL found bugs component library'de merkezi düzeltilir. Bir sonraki RTL locale rollout daha düşük maliyetli olur.

Visual Regression Testing

Visual regression localized UI'ın spacing, overflow ve direction davranışını screenshot karşılaştırmasıyla korur. Her locale için her route'u görüntülemek yüksek maliyetlidir. Representative locale matrix daha verimli olabilir. Long-text pseudo locale, RTL ve CJK senaryoları farklı problem sınıflarını kapsar. Critical component'ler her release'te otomatik test edilebilir.

Locale Başına Screenshot

Tier 1 locale'ler critical route screenshot set'ine sahip olabilir. Fixed test data deterministic result sağlar. Dynamic timestamp ve avatar gibi alanlar maskelenir. Baseline locale owner tarafından review edilir. Translation-only değişiklikler expected diff olarak açıklanabilir.

Long Text

Pseudo-long locale en fazla overflow riskini tek scenario'da gösterebilir. Button, tabs ve table header gözlemlenir. Responsive viewport'lar birlikte test edilir. Fixed width regression hızlı bulunur. Sadece desktop screenshot localization riskini tam kapsamaz.

RTL

RTL screenshot layout mirror ve icon yönünü gösterir. Focus state gibi interaction ayrıca capture edilebilir. Modal veya dropdown overlay positioning test edilmelidir. Scrollbar direction bazı browser'larda farklı olabilir. Representative browser matrix project kullanımına göre seçilir.

CJK

CJK screenshot font fallback ve line-break davranışını ortaya çıkarır. Glyph rendering build environment'taki fontla production arasında farklı olmamalıdır. Webfont deterministic yüklenmelidir. Text wrapping baseline ile karşılaştırılır. Component height değişiklikleri regression olarak incelenir.

Button Overflow

Button label container dışına taşmamalıdır. Icon ile text overlap olmamalıdır. Minimum height ve tap target korunmalıdır. Wrap desteklenmiyorsa component genişleyebilmelidir. Snapshot yalnızca class string değil gerçek render sonucu üzerinden alınmalıdır.

Table/Layout Regression

Translated header table column distribution'ını değiştirir. Horizontal scroll gerekiyorsa accessible ve usable olmalıdır. Sticky column RTL'de doğru tarafta kalmalıdır. Cell number formatting width'i etkileyebilir. Visual test representative row data kullanmalıdır.

CI/CD i18n Quality Gates

i18n quality gate hataların production'a ulaşmadan otomatik bulunmasını sağlar. Missing translation, invalid ICU syntax ve placeholder mismatch temel kontrollerdir. Unknown veya unused key code health'i korur. Translation completeness locale tier'a göre threshold kullanabilir. RTL screenshot test critical design system değişikliklerinde ek gate olarak çalışabilir.

Missing Translation

Source catalog ile target locale key set'i karşılaştırılır. Tier 1 locale eksik key varsa release bloke edilebilir. Lower tier locale fallback ile devam edebilir. Missing list TMS'e otomatik issue olarak gönderilebilir. Generated report namespace owner'ı gösterir.

Invalid ICU Syntax

ICU message parse edilmeden production'a gitmemelidir. Eksik brace veya invalid plural branch runtime error oluşturabilir. CI bütün target messages'ı parser ile validate eder. TMS de edit sırasında aynı kontrolü sunabilir. Parser version runtime library ile uyumlu olmalıdır.

Missing Placeholder

Source {count} içerirken target message bunu kaybetmemelidir. AST comparison placeholder set'lerini kontrol eder. Extra unknown placeholder da hata sayılmalıdır. Optional variable contract explicit olarak modellenebilir. CI message publish'i durdurur.

Unknown Key

Source code resource catalog'da bulunmayan key kullanıyorsa build hata vermelidir. Dynamic string-generated key bu kontrolü zorlaştırır. Known key type generation sorunu azaltır. Runtime unknown event yine telemetry üretir. Refactoring stale reference'ları bu gate yakalar.

Unused Key

Catalog'da olup source code'da kullanılmayan key translation maliyeti yaratır. Detector static reference'ları analiz eder. Dynamic key convention varsa allowlist gerekir. Key hemen silinmeden deprecation süresi uygulanabilir. Cleanup report periyodik çalıştırılabilir.

Translation Completeness

Completeness yalnızca total percentage değildir. Critical journey key'leri ayrı zorunlu set olabilir. Tier 1 için yüzde yüze yakın threshold kullanılabilir. New feature flag untranslated locale'de kapalı kalabilir. Dashboard coverage trend'ini release bazında gösterir.

RTL Screenshot Test

Design system değişikliği pseudo-RTL screenshot suite çalıştırabilir. Unexpected visual diff review gerektirir. Icon direction ve logical spacing regression'ı burada görünür olur. Her translation change için full screenshot suite zorunlu olmayabilir. Affected component selection pipeline süresini dengeler.

Translation'lar Release'ler Arasında Nasıl Yönetilmeli?

Development, staging ve production translation set'leri birbirinden ayrılmalıdır. Developer yeni source key üzerinde çalışırken production yalnızca approved version kullanır. Promotion aynı artifact'ın environment'lar arasında ilerlemesini sağlar. Release tag hangi translation set'inin application version ile kullanıldığını gösterir. Rollback önceki approved artifact'a güvenli dönüş sağlamalıdır.

Dev

Development ortamı incomplete translation kabul edebilir. Source language veya pseudo-locale hızlı feedback sağlar. New key TMS'e otomatik sync edilir. Draft translation preview edilebilir. Production credentials dev environment'ta kullanılmamalıdır.

Staging

Staging yalnızca review'a hazır veya approved translation'ları test edebilir. Linguistic QA gerçek release candidate üzerinde çalışır. Visual screenshots alınır. Missing key warning açık tutulur. Production publish öncesi locale readiness burada doğrulanır.

Production

Production yalnızca approved immutable translation version kullanmalıdır. Runtime resource CDN'den geliyorsa version pinning uygulanabilir. Emergency hotfix controlled approval akışına sahiptir. Missing fallback telemetry izlenir. Production edit doğrudan translator workspace'ten anlık uygulanmamalıdır.

Translation Promotion

Staging'de test edilmiş artifact yeniden build edilmeden production'a promote edilebilir. Bu yaklaşım environment drift'i azaltır. Approval metadata artifact ile birlikte taşınır. Locale bazlı promotion mümkün olabilir. Cross-locale dependency varsa completeness gate korunur.

Release Tag

Translation release tag code release veya bağımsız localization version'ını tanımlar. Incident hangi content set'inin aktif olduğunu hızlı gösterir. TMS snapshot tag ile eşleşebilir. CDN manifest aynı version'ı taşır. Rollback UI'sı human-readable release açıklaması gösterebilir.

Rollback

Yanlış translation production'a çıkarsa hızlı geri dönüş gerekir. Immutable previous version cache'de veya artifact store'da tutulur. Rollback bütün locale'i veya tek namespace'i kapsayabilir. Legal string rollback approval gerektirebilir. Incident sonrası root cause process iyileştirmesine dönüştürülmelidir.

Feature Flag ile Locale Rollout

Feature kodu hazır olduğunda bütün locale translation'larının aynı anda tamamlanması şart olmayabilir. Locale-specific feature flag kontrollü rollout sağlar. Tier 1 locale hazırken experimental locale feature'ı daha sonra açılabilir. Market restriction ayrı flag dimension olabilir. Translation ready gate flag activation öncesinde otomatik kontrol edilebilir.

Feature Kodunun Hazır Olması

Engineering feature'ı main branch'e merge etmiş olabilir. Source translation key'leri TMS'e gönderilir. Default locale testleri tamamlanır. Diğer locale'ler henüz draft durumda olabilir. Feature flag kullanıcıya erken görünmesini engeller.

Translation'ın Henüz Hazır Olmaması

Incomplete translation kullanıcıya mixed-language experience verebilir. Critical journey için feature kapalı kalabilir. Low-risk locale fallback policy product tarafından kabul edilebilir. TMS readiness status deployment system'e aktarılabilir. Manual spreadsheet kontrolü yerine automated gate tercih edilmelidir.

Locale Bazlı Flag

Flag evaluation current locale'i dimension olarak kullanabilir. Feature yalnızca approved locale listesinde açılır. User switch target locale'e geçtiğinde feature availability değişebilir. Bu behavior UX açısından açıklanmalıdır. Flag config locale taxonomy ile validated olmalıdır.

Market Bazlı Rollout

Feature legal veya commercial nedenlerle yalnızca belirli markette kullanılabilir. Market flag language flag'den ayrı tutulmalıdır. Aynı locale farklı markette farklı availability gösterebilir. Backend authorization ve business rule frontend flag'e güvenmemelidir. Analytics rollout result'ı market ve locale bazında segment edebilir.

Translation Ready Gate

TMS approved status release system tarafından okunabilir. Critical namespace coverage threshold karşılanmadan flag açılmaz. Legal content ayrıca explicit approval gerektirir. Gate override yalnızca yetkili role açık olmalıdır. Exception audit log'a yazılır.

Accessibility ve i18n

i18n ve accessibility birbirinden bağımsız kalite alanları değildir. Document language screen reader telaffuzunu etkiler. Localized ARIA label ve error message kullanıcıya aynı language experience'ı sağlar. RTL keyboard navigation ve focus order görsel yönle uyumlu olmalıdır. Accessibility testleri her önemli locale dimension'ını temsil etmelidir.

HTML lang

HTML root lang current document language'ini belirtir. Value BCP 47 uyumlu olmalıdır. Server-side render initial value'yu doğru üretmelidir. Client locale switch value'yu günceller. Screen reader pronunciation ve browser language processing bundan faydalanır.

Mixed-Language Content

Page içinde başka dilde quote veya product name bulunabilir. İlgili element inline lang ile işaretlenebilir. Screen reader doğru pronunciation engine'e geçebilir. Her foreign technical term için gereksiz markup da readability'yi zorlaştırabilir. Meaningful language switch noktaları seçilmelidir.

ARIA Labels

Icon-only button ARIA label translation resource kullanmalıdır. Visible text yok diye localization kapsamından çıkarılmamalıdır. Label source key component ile birlikte versionlanır. Placeholder gerekiyorsa aynı validation uygulanır. Screen reader test target locale'de yapılmalıdır.

Form Errors

Validation error kullanıcı form locale'iyle aynı dilde olmalıdır. Backend machine error code client message'a map edilebilir. Error field association ARIA üzerinden korunmalıdır. Translation uzaması layout'u bozmamalıdır. Critical form message plain language guideline'ına uymalıdır.

Alt Text

Meaningful image alt text localized olmalıdır. Decorative image boş alt kullanmaya devam eder. CMS content image alt text'i editorial localization workflow'unda tutulabilir. Brand logo alt description translation policy'ye göre değişebilir. Image içindeki gömülü text mümkünse kullanılmamalıdır.

Keyboard Navigation

Language switch keyboard ile erişilebilir olmalıdır. RTL visual order focus order ile anlaşılır biçimde uyumlu kalmalıdır. CSS order değişikliği DOM order'dan farklılaştığında problem oluşabilir. Logical layout DOM semantics'i bozmamalıdır. E2E keyboard tests LTR ve RTL representative locale'lerde çalıştırılabilir.

Screen Reader Dil Değişimini Nasıl Anlar?

Screen reader document ve element üzerindeki language metadata'sını kullanarak telaffuz modelini değiştirebilir. Root lang page'in temel dilini belirtir. Inline farklı language içeriği ayrı lang alabilir. Marka veya kod isimleri bazen özel pronunciation strategy gerektirir. Locale switch sonrası document title ve language metadata birlikte güncellenmelidir.

Document Language

Document language screen reader'ın default pronunciation davranışını belirler. Yanlış value Türkçe metnin English ses kurallarıyla okunmasına neden olabilir. Server initial markup doğru language'i taşımalıdır. Client navigation yeni locale'e geçtiğinde root attribute update edilir. Automated accessibility test attribute presence'i kontrol edebilir.

Inline lang

Sentence içindeki foreign language phrase kendi lang değeriyle işaretlenebilir. Screen reader geçici olarak başka pronunciation kullanabilir. User name için language bilinmiyorsa tahmin etmek gerekmez. CMS editor inline language metadata ekleyebilir. Excessive markup maintainability'yi zorlaştırmamalıdır.

Telaffuz

Doğru language tag pronunciation kalitesini artırır fakat her product name'i kusursuz okutmayabilir. Screen reader engine'leri farklı davranabilir. Critical abbreviation expanded accessible label ile desteklenebilir. Phonetic hack metne görünür biçimde eklenmemelidir. Accessibility user testing gerçek cihazlarda yapılabilir.

Kod/Marka İsimlerinin Yönetimi

Code token'ları doğal language gibi okunmayabilir. Markaların resmi pronunciation tercihi olabilir. Visible brand text değiştirilmeden accessible context sağlanabilir. Translation do-not-translate list bu değerleri korur. Screen reader workaround platform-specific hale gelmeden önce gerçek user impact test edilmelidir.

i18n Observability

i18n production'da ölçülmediğinde eksik translation sorunları yalnızca support ticket ile fark edilir. Missing-key count ve fallback rate temel teknik sinyallerdir. CDN latency veya load error runtime delivery problemlerini gösterir. Locale distribution product kullanımını anlamaya yardım eder. Language switch failure kullanıcı kontrolünün çalışmadığını doğrudan ortaya çıkarır.

Missing-Key Count

Her missing key event locale ve namespace ile sayılabilir. Unique key ve total occurrence ayrı metric olarak tutulabilir. Deployment sonrası spike regression gösterebilir. Raw user data metric'e eklenmemelidir. Alert critical locale threshold'una göre açılabilir.

Fallback Rate

Fallback rate exact locale yerine base veya default message kullanım oranıdır. Yüksek oran translation freshness sorununa işaret eder. Normal experimental locale daha yüksek fallback kabul edebilir. Tier 1 için düşük SLO hedeflenebilir. Key bazlı ranking en sık eksik content'i gösterir.

Translation Load Error

CDN timeout veya invalid JSON resource load'u bozabilir. Error locale, namespace ve version metadata'sı taşır. Client safe fallback kullanabilir. Retry exponential backoff ile uygulanabilir. Error rate network ve publish probleminden hangisi olduğunu ayırmalıdır.

Translation CDN Latency

Runtime translation loading navigation latency'yi etkileyebilir. Edge cache hit ve origin fetch ayrı ölçülmelidir. P95 veya P99 locale bazında izlenebilir. Büyük namespace response size latency'yi artırabilir. Prefetch ve caching optimizasyonu bu metric üzerinden değerlendirilir.

Locale Distribution

Aktif user locale dağılımı roadmap ve QA yatırımını yönlendirebilir. Browser detected ve explicit selected locale ayrı tutulabilir. Rare locale yine enterprise contract nedeniyle Tier 1 olabilir. Metric privacy-safe aggregate olarak kullanılabilir. Trend yeni market adoption'ını gösterebilir.

Locale Switch Failure

Language switch sonrası navigation veya resource load başarısız olabilir. Event source locale, target locale ve route bilgisini taşır. Preference save failure ayrı metric'tir. High error rate particular locale resource problemine işaret edebilir. User-facing retry veya fallback sağlanmalıdır.

i18n KPI'ları

Teknik metric'ler i18n sisteminin sağlığını gösterirken KPI'lar kullanıcı ve business etkisini ölçer. Translation coverage ve freshness operasyon hızını ifade eder. Linguistic defect rate kaliteyi, top-task success usability'yi gösterir. Support ticket ve conversion locale bazında karşılaştırılabilir. Bu veriler localization yatırımının gerçek ürün sonucuyla bağını kurar.

Translation Coverage

Coverage approved target key sayısının required key set'ine oranı olarak ölçülebilir. Critical journey ayrıca weighted olabilir. Fallback ile çalışan key “tam çevrilmiş” sayılmamalıdır. Tier bazında hedef farklıdır. Dashboard namespace owner'a eksik alanı gösterir.

Translation Freshness

Source değiştikten sonra target translation'ın güncel hale gelme süresini gösterir. Stale key sayısı ayrıca izlenebilir. Release hızı arttıkça freshness daha önemli hale gelir. TMS workflow lead time bunun driver'ıdır. Tenant override freshness ayrı metric olabilir.

Lead Time

Key merge ile approved translation production publish arasındaki süre ölçülür. Queue, translation ve review aşamaları ayrı breakdown yapılabilir. Slow locale bottleneck reviewer kapasitesinden kaynaklanabilir. Automation repetitive waiting süresini azaltabilir. High-risk content daha uzun SLA taşıyabilir.

Linguistic Defect Rate

Linguistic QA veya production feedback'te bulunan translation hataları release başına ölçülebilir. Severity yanlış terminology, grammar veya misleading meaning gibi kategorilere ayrılır. Machine-assisted content ayrıca segment edilebilir. Trend glossary veya reviewer değişikliğinin etkisini gösterir. Defect yalnızca typo sayısı değildir.

Top-Task Success by Locale

Kullanıcının en önemli işi başarıyla tamamlayıp tamamlamadığı locale bazında ölçülebilir. Checkout veya report creation örnek olabilir. Translation quality yalnızca text metric değil task performance üzerinden değerlendirilir. Locale cohort'lar user mix farkı nedeniyle dikkatli karşılaştırılmalıdır. UX research quantitative metriği tamamlar.

Support Ticket Rate by Locale

Belirli locale'de support ticket oranı translation veya usability problemine işaret edebilir. Ticket category localization tag'i taşıyabilir. Düşük usage locale raw count ile değil user-normalized rate ile değerlendirilmelidir. Repeated terminology confusion glossary improvement'a yol açabilir. Support feedback localization backlog'a otomatik aktarılabilir.

Revenue/Conversion by Locale

Public commerce ürünlerinde locale conversion farkı localization investment sonucu olabilir. Ancak pricing, market ve user acquisition mix gibi birçok başka faktör vardır. Causal attribution dikkatli yapılmalıdır. A/B test locale-specific copy improvement'ı ölçebilir. Revenue tek kalite göstergesi olarak kullanılmamalıdır.

Localization Quality Nasıl Ölçülmeli?

Localization quality tek bir grammar score'a indirgenemez. Linguistic correctness, terminology, functional accuracy ve layout birlikte değerlendirilmelidir. Cultural appropriateness yanlış veya rahatsız edici ifadeleri önler. Accessibility target locale'de aynı seviyede korunmalıdır. Scorecard farklı dimension'ları ayrı puanlayarak gerçek problem alanını görünür hale getirir.

Linguistic Correctness

Grammar, spelling ve meaning doğruluğu temel quality dimension'dır. Native reviewer context içinde değerlendirme yapar. Source ambiguity target hatası gibi görünüyorsa source issue olarak işaretlenir. Automated spellcheck yardımcı olabilir. Final accountability approved reviewer'dadır.

Terminology

Approved glossary term'lerinin doğru kullanımı ölçülür. Aynı feature'ın farklı sayfalarda başka isim alması defect olabilir. Automated terminology checker bazı ihlalleri yakalar. Contextual inflection nedeniyle exact string match yeterli olmayabilir. Reviewer semantic consistency'yi değerlendirir.

Functional Accuracy

Translation doğru olsa bile yanlış key yanlış yerde gösterilebilir. Placeholder value veya plural branch hatası functional defect'tir. E2E ve linguistic QA birlikte bunu bulabilir. Link destination target locale'de doğru olmalıdır. Error message gerçek system state'i açıklamalıdır.

Layout

Text kesilmemeli ve component usable kalmalıdır. RTL alignment, button overflow ve table wrapping kontrol edilir. Font missing glyph layout defect sayılabilir. Visual regression automatic detection sağlar. Human reviewer readability ve hierarchy'yi değerlendirir.

Cultural Appropriateness

Literal doğru ifade target culture'da doğal veya uygun olmayabilir. Example name, imagery veya tone ayrıca incelenebilir. Market reviewer sensitive topic'leri değerlendirebilir. Stereotype ve gereksiz cultural assumption'dan kaçınılmalıdır. Product intent korunarak local expression seçilir.

Accessibility

Localized screen reader label visible action ile uyumlu olmalıdır. Document language doğru set edilir. Keyboard navigation text expansion nedeniyle bozulmamalıdır. Alt text target language'e çevrilir. Accessibility defect linguistic review'dan ayrı kategoride takip edilebilir.

Kurumsal i18n Ownership Modeli

i18n tek bir localization manager veya frontend geliştiricinin sorumluluğu değildir. Engineering platformu, product locale roadmap'i ve localization linguistic quality'yi yönetir. Design RTL ve expansion readiness üzerinde çalışır. Legal ve marketing kendi critical content alanlarını onaylar. Customer Success gerçek kullanıcı geri bildirimini governance sistemine taşır.

Engineering

Engineering locale resolver, formatter, translation API ve CI gate'lerden sorumludur. Runtime reliability ve performance monitoring bu alana girer. Developer guideline key ve placeholder standardını açıklar. Infrastructure TMS integration'ını otomatikleştirir. Engineering linguistic approval vermek zorunda değildir.

Product

Product hangi locale'in neden destekleneceğine karar verir. Feature rollout ve locale tier hedeflerini belirler. Translation eksikliğinin user impact'ini önceliklendirir. User research localization requirement'larını besler. Product terminology source language'de net olmalıdır.

Localization

Localization translator, reviewer ve glossary workflow'unu yönetir. Quality SLA ve linguistic defect triage bu ekibin alanıdır. TMS operasyonu burada sahiplenilebilir. Engineering ile context tooling üzerinde çalışır. Market reviewer network'ü yönetilebilir.

Design

Design system text expansion ve RTL-ready component üretir. Locale-specific typography standardını belirler. Language switch UX tasarımını yapar. Visual QA finding'leri component pattern'lerine dönüştürür. Fixed text assumptions design review'da sorgulanır.

Legal

Legal high-risk content source ve target approval'ını yönetir. Market-specific version policy belirler. Effective date ve audit requirement'larını tanımlar. Machine translation kullanım sınırına karar verebilir. Engineering approval gate'i teknik olarak uygular.

Marketing/SEO

Marketing localized metadata ve market copy üzerinde çalışır. SEO ekibi URL, hreflang ve sitemap stratejisini yönetir. Keyword research target language'de yeniden yapılmalıdır. Literal source translation search intent'i her zaman karşılamaz. CMS ve TMS workflow'ları bu ekiplerle entegre olur.

Customer Success

Customer Success kullanıcıların gerçek terminology ve usability sorunlarını en erken görebilen ekiplerden biridir. Ticket locale metadata'sı localization defect trend'ini gösterebilir. Enterprise tenant override talepleri buradan gelebilir. Feedback product ve localization backlog'una aktarılır. Support documentation aynı terminology standardını kullanmalıdır.

i18n Governance

Governance kurumsal i18n'in ekipler büyüdükçe aynı kalite standardını korumasını sağlar. Supported locale policy ürünün neyi taahhüt ettiğini açıklar. Key ve terminology standardı geliştiriciler ile translator'lar için ortak dil oluşturur. Quality SLA release ve fallback kararlarını belirler. Deprecation policy artık desteklenmeyen locale ve key'lerin güvenli biçimde kaldırılmasını sağlar.

Supported Locale Policy

Policy hangi locale'lerin production support aldığını listeler. Tier, owner ve rollout status metadata olarak tutulabilir. Her locale'in backend notification ve SEO coverage kapsamı belirtilir. Experimental locale kullanıcıya açıkça etiketlenebilir. Liste configuration repository'de machine-readable tutulabilir.

Translation Key Standard

Naming, namespace ve description requirement dokümante edilir. Dynamic key generation mümkün olduğunca sınırlandırılır. Rename process TMS migration'ını içerir. CI standard dışı key'i reddedebilir. Örnekler onboarding dokümanında gösterilir.

Terminology Standard

Source terminology glossary olmadan target consistency sağlamak zordur. Approved product term'ler merkezi listede tutulur. Change owner ve effective release belirlenir. Do-not-translate term'ler ayrıca yönetilir. Localization ve support aynı termbase'i kullanabilir.

Quality SLA

Tier 1 locale için translation lead time ve defect threshold tanımlanabilir. Critical legal content ayrı SLA taşır. Missing translation maximum rate production SLO olabilir. Escalation owner bellidir. SLA business contract requirement'larıyla uyumlu tutulur.

Release Policy

Hangi translation status production'a çıkabilir açıkça belirlenir. Draft content normal kullanıcıya gösterilmez. Feature flag incomplete locale'i korur. Emergency hotfix approval süreci tanımlıdır. Rollback responsibility localization ve platform ekipleri arasında paylaşılır.

Deprecation Policy

Locale veya translation key kaldırılması consumer impact yaratabilir. Usage metric önce kontrol edilir. User preference deprecated locale'den desteklenen fallback'e migrate edilir. SEO URL redirect planı hazırlanır. TMS resource retention audit requirement'a göre sürdürülür.

Yeni Bir Dil Production'a Nasıl Eklenmeli?

Yeni locale eklemek yalnızca translation file oluşturmakla bitmez. Market ihtiyacı, identifier, font, layout, SEO ve QA aynı rollout planında bulunmalıdır. TMS workflow translation operasyonunu hazır hale getirir. Feature flag kontrollü kullanıcı açılımı sağlar. Production metrics gerçek kullanım sırasında beklenmeyen fallback ve layout problemlerini gösterir.

1. Market Gereksinimini Onayla

Locale talebi user demand, contract veya market strategy ile doğrulanır. Support capacity değerlendirilir. Legal ve payment requirement varsa scope'a eklenir. Tier seviyesi belirlenir. Success metric rollout öncesinde tanımlanır.

2. Locale Identifier Belirle

BCP 47 uyumlu en uygun tag seçilir. Gereksiz region veya script eklenmez. Application locale registry güncellenir. TMS, CMS ve routing mapping doğrulanır. Fallback chain yeni locale için tanımlanır.

3. Translation Kaynaklarını Oluştur

Required namespace listesi source catalog'dan oluşturulur. TMS target locale project'i açılır. Glossary ve style guide hazırlanır. Critical legal resource ayrı workflow alır. Build veya runtime artifact path configuration'a eklenir.

4. Font/Layout Uyumluluğunu Test Et

Script glyph coverage doğrulanır. Text expansion veya RTL gerekiyorsa design system test edilir. Representative route screenshot'ları alınır. Mobile viewport ihmal edilmez. Font performance budget kontrol edilir.

5. TMS Workflow'u Kur

Translator ve reviewer assignment yapılır. Permission least privilege ile verilir. Translation memory ve glossary bağlanır. Due date release planına eklenir. CI sync test edilir.

6. Translation Yap

Translator source message ve context üzerinden target content oluşturur. Machine-assisted draft izin verilen içerikte kullanılabilir. Placeholder syntax korunur. Ambiguous source string issue olarak engineering'e döner. Progress coverage dashboard'da görünür olur.

7. Linguistic QA

Native reviewer product içinde message'ları inceler. Terminology ve tone kontrol edilir. Critical user journey öncelikli tutulur. Defect TMS'e key üzerinden raporlanır. Fix yeniden review edilir.

8. Visual/RTL QA

Screenshot ve manual UI test layout'u doğrular. RTL locale ise direction ve icon behavior incelenir. Long text overflow kontrol edilir. Font rendering farklı browser'larda test edilir. Critical defect rollout'u bloke eder.

9. SEO Yapılandır

Public site locale URL'leri crawl edilebilir hale gelir. Hreflang alternate set güncellenir. Sitemap yeni URL'leri içerir. Localized metadata hazırdır. Redirect ve canonical policy test edilir.

10. Feature Flag ile Yayınla

İlk rollout küçük kullanıcı grubuna yapılabilir. Translation completeness gate flag'i kontrol eder. Support ekipleri hazır tutulur. Metrics baseline ile karşılaştırılır. Problem varsa hızlı disable yapılabilir.

11. Production Metrics İzle

Missing key ve fallback rate takip edilir. Locale switch failure incelenir. Support ticket ve task success ölçülür. Translation CDN latency kontrol edilir. İlk haftalardaki finding'ler localization backlog'una eklenir.

Mevcut Tek Dilli Uygulamaya i18n Nasıl Eklenir?

Tek dilli büyük uygulamayı bir anda tamamen internationalized hale getirmek yüksek riskli olabilir. Önce hard-coded string ve formatting inventory çıkarılmalıdır. Shared component ve en yoğun user journey'lerden kademeli başlanabilir. Translation key extraction ve namespace yapısı standardize edilir. CI yeni hard-coded string borcunun tekrar oluşmasını engeller.

Hard-Coded String Inventory

Source code static analysis kullanıcıya görünen literal string'leri bulabilir. Template, validation ve backend notification'lar birlikte taranmalıdır. False positive classification gerekir. High-traffic route'lar önceliklendirilir. Inventory migration progress metriği olarak kullanılır.

Locale-Aware Format Audit

Manual date ve currency formatter'lar bulunur. Number string concatenation noktaları listelenir. Time zone assumption'ları ayrıca kaydedilir. Shared formatting service hedef architecture olarak oluşturulur. Migration sırasında regression tests eklenir.

CSS/Layout Audit

Fixed width ve left/right property yoğunluğu belirlenir. Component library pseudo-long ve RTL mode'da açılır. En fazla kullanılan primitive'ler önce düzeltilir. Feature-specific layout sonra migrate edilir. Design token ve logical property standardı yazılı hale getirilir.

Translation Key Extraction

Hard-coded string semantic key'e dönüştürülür. Aynı text'in farklı context'leri yanlışlıkla birleştirilmez. Description metadata eklenir. Source locale resource oluşturulur. CI unknown key ve source completeness kontrolü yapar.

Namespace Oluşturma

Mevcut application domain yapısına göre namespace'ler belirlenir. Tek dev common file'dan kaçınılır. Lazy loading ihtiyacı dikkate alınır. Ownership her namespace'e atanır. TMS project structure aynı mantığı takip eder.

En Yoğun Kullanılan Journey'lerden Başlamak

Login, dashboard veya checkout gibi yüksek traffic flow önce migrate edilebilir. Kullanıcı value daha erken görülür. Shared component değişikliği diğer route'lara da fayda sağlar. Support feedback ilk rollout'ta toplanır. Low-use admin ekranları daha sonra ele alınabilir.

Kademeli Migration

Application bir süre hard-coded ve translated ekranları birlikte barındırabilir. Yeni feature'larda translation key zorunlu hale getirilir. Existing debt sprint bazında azaltılır. Pseudo-locale migration coverage'ını görsel olarak gösterir. Tamamlanma criteria yalnızca file count değil runtime fallback ve hard-coded string metriğidir.

i18n Refactoring Sırası

Migration sırası en yüksek reuse ve kullanıcı etkisini önce hedeflemelidir. Shared components bütün application'a yayılmış olduğu için yüksek kaldıraç sağlar. Authentication ve navigation kullanıcı her oturumda gördüğü alanlardır. Core product flow daha sonra locale-ready hale getirilir. Backend notification ve report katmanları frontend tamamlanmasını beklemeden paralel ilerleyebilir.

Shared Components

Button, input ve modal hard-coded text'ten arındırılır. Logical CSS ve flexible width eklenir. Date veya number display primitive locale-aware formatter kullanır. Accessibility label localization input'u kabul eder. Story set pseudo locale ve RTL fixture kazanır.

Authentication

Login public entry olduğu için early localization yüksek değer sağlar. Browser language ilk tahmin olarak kullanılabilir. Error code'lar translated message'a map edilir. Password e-mail aynı locale flow'u izler. Language switch login olmadan çalışabilmelidir.

Navigation

Menu ve breadcrumbs route locale'iyle senkron hale getirilir. Language switch equivalent route'a geçer. URL strategy burada netleşir. Document title localized olur. Back ve direct navigation test edilir.

Core Product Flows

Kullanıcının temel görevleri namespace bazında migrate edilir. Form validation ve API errors dahil edilir. Date, number ve currency audit tamamlanır. Visual QA representative locale'lerde yapılır. Analytics task success baseline oluşturur.

Backend Notifications

E-mail ve push locale resolver'a bağlanır. User preference queue job'larına güvenli aktarılır. Template TMS workflow'una alınır. Legal footer ayrı governance alır. Delivery test farklı locale'lerde yapılır.

Reports/PDF

Report renderer Unicode font ve locale formatter kullanır. Column heading translation resource'tan gelir. PDF RTL ve page-break testleri yapılır. Historical reproduction için translation version policy belirlenir. Export data format human-readable rapordan ayrılır.

Admin Screens

Admin düşük traffic olsa bile internal support kalitesini etkiler. Migration en son yapılabilir fakat tamamen unutulmamalıdır. Operational error messages locale-aware hale gelir. Permission terminology glossary ile uyumlu olur. Experimental locale için English fallback bilinçli kabul edilebilir.

i18n Performans Optimizasyonu

i18n performance en çok resource yükleme ve formatter tekrarından etkilenir. Active locale only yaklaşımı gereksiz bundle'ı azaltır. Namespace splitting feature boundary'lerine göre yapılır. CDN ve browser cache translation resource'larını hızlandırır. Unused key cleanup hem transfer boyutunu hem translation operasyon maliyetini düşürür.

Active Locale Only

Client yalnızca current locale translation'larını yükler. Language switch target resource'u gerektiğinde getirir. Server component architecture translation'ı server'da tutabilir. Default fallback küçük critical bundle olabilir. Memory usage çok locale'li long-lived application'da ayrıca izlenir.

Namespace Splitting

Large catalog feature namespace'lerine bölünür. Initial route yalnızca gerekli parçaları yükler. Çok granular splitting request overhead yaratabilir. Shared common bundle cache edilir. Route dependency manifest optimum grouping'i sağlar.

Lazy Loading

Translation namespace code chunk ile aynı anda lazy load edilebilir. Navigation pending state resource beklerken kullanıcıya feedback verir. Preload likely-next route latency'yi azaltabilir. Load error fallback strategy kullanır. Retry infinite loop oluşturmamalıdır.

CDN

CDN immutable translation artifact'ını edge üzerinden sunar. Locale ve version URL path'inde açık olabilir. Long cache TTL bandwidth'i azaltır. Origin protection publish sırasında önemlidir. Metrics cache hit ve latency'yi gösterir.

Resource Caching

Browser memory veya HTTP cache aynı namespace'in tekrar yüklenmesini önler. Cache invalidation translation version ile çözülür. User tenant override resource'u tenant-scoped key kullanır. Sensitive translation aslında PII içermemelidir. Service worker offline strategy gerekiyorsa stale policy belirlenir.

Unused Key Cleanup

Ölü key runtime resource boyutunu artırır. TMS translator gereksiz string'e zaman harcar. Static analysis candidate list üretir. Dynamic reference allowlist ile korunur. Cleanup release öncesi artifact diff'inde görünür olur.

Çok Fazla Translation Dosyası Performansı Bozar mı?

Dosya sayısı tek başına performans probleminin tamamını açıklamaz. Çok küçük namespace'ler request count'u artırabilir. Tek dev bundle ise initial transferi büyütür. Route-level grouping ve HTTP caching doğru dengeyi sağlar. Measurement gerçek navigation timing ve bundle size üzerinden yapılmalıdır.

Request Count

Her namespace ayrı request ise initial page onlarca network çağrısı yapabilir. HTTP/2 ve HTTP/3 overhead'i azaltsa da latency tamamen yok olmaz. Related small namespace'ler birleştirilebilir. Server-side aggregation başka seçenektir. Network waterfall profiler ile izlenmelidir.

Bundle Size

Tek translation file bütün feature copy'sini taşıyorsa kullanıcı kullanmadığı content'i indirir. Locale sayısı arttıkça sorun büyür. Code split ile birlikte resource split uygulanabilir. Compression repeated key pattern'lerine yardımcı olur. Raw source size değil transferred ve parsed size ölçülmelidir.

Route-Level Namespace

Route hangi namespace'i gerektiğini önceden tanımlayabilir. Router navigation sırasında paralel load başlatır. Parent layout shared namespace'i cache'den kullanır. Nested child yalnızca ekstra resource getirir. Route manifest build sırasında doğrulanabilir.

Prefetch

User likely route link üzerine geldiğinde translation namespace prefetch edilebilir. Mobile data usage dikkate alınmalıdır. Browser idle time düşük priority fetch için kullanılabilir. Prefetch versioned cache'e yazılır. User route'a gitmezse gereksiz transfer sınırlı tutulmalıdır.

HTTP Caching

Versioned translation file immutable cache header kullanabilir. ETag mutable endpoint'lerde conditional request sağlar. CDN ve browser cache policy uyumlu olmalıdır. Locale switch geri döndüğünde resource cache'den gelir. Debug environment caching'i gerektiğinde devre dışı bırakabilir.

Production İçin Örnek Locale Resolution Akışı

Production resolver açık priority chain kullanarak her request'te aynı sonucu üretmelidir. URL explicit locale varsa ilk kaynak olarak kabul edilir. Authenticated user ve tenant preference sonraki katmanlarda değerlendirilir. Cookie ve browser header tahmin görevi görür. Sonuç supported locale matching ile normalize edilir ve kullanıcıya her zaman manuel override sağlanır.

1. Locale URL'de Varsa Kullan

Path veya domain locale'i parse edilir. BCP 47 ve supported allowlist kontrolü yapılır. Geçerliyse request context'e atanır. User preference farklı olsa bile explicit URL korunur. Gerekirse son seçim profile'a sync edilir.

2. Authenticated User Preference'ı Kontrol Et

URL locale taşımıyorsa user profile okunur. Supported preference varsa seçilir. Page locale-prefixed URL kullanıyorsa uygun redirect yapılır. Invalid legacy value temizlenebilir. Preference current organization policy'sini geçebilir.

3. Tenant Default'u Kontrol Et

User preference yoksa organization default kullanılır. Tenant configuration cache'den okunabilir. Supported locale validation uygulanır. Market default ile language default ayrı tutulur. Tenant value missing ise sonraki adıma geçilir.

4. Cookie'yi Kontrol Et

Anonymous previous choice cookie'de bulunabilir. Value validate edilir. Expired veya deprecated locale ignore edilir. Cookie current browser session için preference continuity sağlar. Explicit user switch cookie'yi yeniler.

5. Accept-Language ile İlk Tahmin Yap

Header preferred language ranges içerir. Matcher supported locale listesinde en yakın sonucu arar. Region-specific exact match bulunmazsa base language düşünülebilir. Header kullanıcı choice olmadığı için düşük priority'dedir. Sonuç user'a değiştirilebilir şekilde sunulur.

6. Desteklenen En Yakın Locale'ye Match Et

Raw requested locale doğrudan resource lookup'a verilmemelidir. Matching exact, base language ve default strategy kullanabilir. Script farkı korunmalıdır. Unsupported value predictable fallback üretir. Final locale canonical formatta tutulur.

7. Kullanıcıya Her Zaman Override İmkânı Ver

Automatic detection hiçbir zaman user control'ü kapatmamalıdır. Language switch her önemli page'den erişilebilir olur. User selection persistence katmanına yazılır. Current route equivalent locale'e geçirilir. Override telemetry automatic detection kalitesini ölçmeye yardım eder.

Production-Ready i18n Veri Akışı

Production-ready veri akışı developer source key'inden kullanıcıya gösterilen approved translation'a kadar bütün aşamaları izlenebilir hale getirir. CI syntax ve placeholder contract'ını doğrular. TMS translation ile human review'u yönetir. Staging visual ve linguistic QA için güvenli ortam sağlar. Versionlanan resource production CDN'e yayınlanır ve missing/fallback metric'leri sürekli izlenir.

1. Developer Semantic Translation Key Ekler

Key feature ve domain context'ini açıkça taşır. Source message tam sentence olarak yazılır. Placeholder metadata eklenir. Description ve screenshot relation mümkünse aynı değişiklikte oluşturulur. Pull request naming standardını kontrol eder.

2. CI Key ve Placeholder'ları Validate Eder

Message parser syntax doğrulaması yapar. Placeholder source contract'a uygundur. Duplicate veya invalid key naming hata üretir. Existing target translation stale olarak işaretlenebilir. Başarılı catalog version hash oluşturur.

3. Key TMS'e Gönderilir

Pipeline delta sync yapar. TMS source version ve metadata'yı kaydeder. Target locale tasks otomatik açılır. Deprecated key status korunur. Sync log release traceability sağlar.

4. Translation/AI Draft Oluşturulur

Translator veya approved machine-assisted workflow ilk target'ı üretir. Glossary ve translation memory öneri sunar. PII context içinde bulunmaz. High-risk content automatic approval almaz. Draft status açıkça işaretlenir.

5. Human Review Yapılır

Reviewer grammar ve terminology kontrolü yapar. Context ve screenshot üzerinden UI anlamını değerlendirir. Critical content specialist review'a gider. Placeholder değiştirilmemiş olmalıdır. Approved status sonraki aşamayı açar.

6. Approved Translation Staging'e Alınır

Artifact immutable staging version olarak publish edilir. Application release candidate aynı version'ı kullanır. Missing key warning görünürdür. QA actual route'larda content'i inceler. Production'dan farklı draft resource karışmamalıdır.

7. Visual ve Linguistic QA Yapılır

Native reviewer user journey'i tamamlar. Screenshot regression overflow ve RTL hatalarını bulur. Functional placeholder değerleri kontrol edilir. Defect severity belirlenir. Critical issue artifact promotion'ı engeller.

8. Translation Versionlanır

Approved ve QA geçmiş resource set'i release tag alır. Hash veya semantic version kullanılabilir. TMS snapshot immutable tutulur. Application manifest version'a referans verir. Rollback previous tag ile mümkündür.

9. Production/CDN'e Publish Edilir

Artifact production distribution alanına promote edilir. CDN immutable path cache'ler. Manifest yeni version'ı kontrollü şekilde aktif eder. Locale-by-locale rollout yapılabilir. Publish event audit log'a yazılır.

10. Missing/Fallback Metrics İzlenir

Production event'leri locale ve namespace bazında toplanır. Unexpected fallback artışı alert oluşturur. Translation load latency izlenir. Support ticket data ile correlation yapılabilir. Finding sonraki release process'ine geri beslenir.

Production'a Çıkmadan Önce i18n Kontrol Listesi

Production checklist teknik ve operasyonel hazırlığın birlikte tamamlandığını doğrular. Hard-coded string, locale resolution, formatting ve fallback kontrol edilir. RTL, Unicode, backend notification ve SEO aynı listeye dahil edilir. Legal approval ile translation rollback yalnızca teknik UI testinden daha yüksek risk taşıyan konuları kapsar. Checklist otomasyonla mümkün olduğunca CI ve release platformuna taşınmalıdır.

Hard-Coded UI String Kaldı mı?

Pseudo-locale ve static scan normal source language kalan metinleri bulur. Debug-only string production kapsamından hariç tutulabilir. ARIA label ve tooltip unutulmamalıdır. Backend-rendered message ayrıca taranır. Yeni hard-coded string lint rule ile engellenir.

Translation Key Standardı Var mı?

Key naming bütün feature'larda aynı convention'ı izlemelidir. Domain ownership açık olmalıdır. Dynamic key generation sınırlandırılmalıdır. Rename policy TMS history'sini korur. CI invalid pattern'ı reddeder.

ICU Pluralization Kullanılıyor mu?

Count-dependent message iki string if statement'ına bırakılmamalıdır. Locale plural rules standard library üzerinden uygulanır. Target locale gerekli category'leri sağlar. Full sentence branch kullanılır. Representative count testleri bulunur.

Locale Resolution Deterministic mi?

URL, profile, tenant, cookie ve header priority'si yazılıdır. Server ve client aynı sonucu üretir. Unsupported locale fallback açıkça tanımlıdır. Resolver unit tests bütün branch'leri kapsar. Production metric default fallback'i izler.

Kullanıcı Dili Manuel Değiştirebiliyor mu?

Language switch her kullanıcı için erişilebilir olmalıdır. Selection automatic detection'ı geçer. Current route mümkünse korunur. Preference persist edilir. Keyboard ve screen reader kullanımına uygun semantics sağlanır.

Fallback Chain Tanımlı mı?

Exact locale, base language ve default order açık olmalıdır. Legal content istisnaları tanımlanır. Tenant override precedence ayrıca yazılır. Fallback raw key üretmez. Telemetry kullanım oranını ölçer.

Date/Time Locale-Aware mı?

Manual date string generation kaldırılmış olmalıdır. Locale formatter kullanılır. Time zone separate context'ten gelir. 12/24 hour preference doğrulanır. DST edge case test edilir.

Currency Doğru Yönetiliyor mu?

Currency locale'den otomatik türetilmemelidir. Amount ve currency code birlikte taşınır. Display locale yalnızca formatting yapar. Minor unit ve rounding business policy'ye uyar. Billing currency user preference'tan ayrı tutulur.

RTL Test Edildi mi?

Pseudo-RTL design system ve critical route'larda çalıştırılır. Logical CSS ve icon direction kontrol edilir. Root lang ve dir doğru set edilir. Mixed-content Bidi testleri bulunur. Actual RTL locale linguistic QA ayrıca yapılır.

Text Expansion Test Edildi mi?

Pseudo-long locale button ve navigation üzerinde denenir. Fixed width component'ler belirlenir. Dialog ve table overflow kontrol edilir. Mobile viewport test edilir. Truncation yalnızca bilinçli UX kararı olarak kullanılır.

Unicode/UTF-8 Baştan Sona Destekleniyor mu?

Frontend, API ve database Unicode content'i kayıpsız taşır. Export dosyaları test edilir. Normalization policy search ve unique alanlarda tanımlıdır. Font glyph coverage farklı script'leri destekler. Legacy integration conversion testleri vardır.

Backend Notification'ları Localized mı?

E-mail, SMS ve push user locale'ini resolve eder. Scheduled job locale policy'si belirlenmiştir. Template glossary ile uyumludur. Links localized route'a gider. Delivery test representative locale'lerde yapılır.

SEO/hreflang Doğru mu?

Public locale URL'leri crawl edilebilir olmalıdır. Hreflang self ve reciprocal relation'lar vardır. Canonical localized content'le uyumludur. Sitemap bütün active locale page'leri kapsar. Browser-language redirect crawler'ı bloke etmez.

Pseudo-Localization CI'da Var mı?

Pseudo locale component preview veya automated testte çalışmalıdır. Hard-coded string detection desteklenir. Text expansion görünür hale gelir. Accent character font coverage'ı test eder. Pipeline tüm build'i gereksiz uzatmadan critical route set'ini kullanabilir.

Missing Translation Gate Var mı?

Tier 1 locale missing required key ile production'a çıkmamalıdır. Lower tier policy ayrıca tanımlıdır. Missing placeholder daha yüksek severity'dir. Dashboard incomplete namespace'i gösterir. Override yalnızca yetkili role açık olur.

Legal Translation Approval Süreci Var mı?

Legal message human-approved olmalıdır. Version ve effective date saklanır. Market-locale mapping doğrulanır. Automatic fallback kapalı olabilir. Audit trail production publish'i gösterir.

Translation Rollback Mümkün mü?

Previous approved artifact erişilebilir olmalıdır. Runtime manifest hızlı version değiştirebilir. Build-time model previous application artifact'a dönebilir. Rollback procedure test edilmelidir. Legal rollback ayrıca approval gerektirebilir.

Accessibility Tüm Locale'lerde Test Edildi mi?

Root lang ve RTL direction doğrulanır. ARIA label translation coverage içindedir. Screen reader representative locale'de test edilir. Keyboard navigation text expansion sonrası bozulmaz. Color veya focus style language change nedeniyle değişmemelidir.

Sık Yapılan Kurumsal i18n Hataları

Kurumsal i18n hatalarının çoğu problemi translation file yönetimine indirgemekten kaynaklanır. Hard-coded string, yanlış plural rule ve locale-market karışıklığı ileride pahalı migration yaratır. Accept-Language veya bayrak gibi kolay sinyaller gereğinden fazla anlam yüklenerek kullanılır. RTL ve performance en sona bırakıldığında yeni locale rollout büyük UI düzeltme projesine dönüşür. Governance ve test altyapısı bu hataların tekrar etmesini önler.

i18n'i Sadece JSON Dosyası Eklemek Sanmak

JSON yalnızca translation resource formatıdır. Locale routing, formatter ve direction ayrı problemdir. Backend notification ve SEO da i18n kapsamına girer. Test ve governance olmadan dosyaların varlığı production quality sağlamaz. Architecture bütün user touchpoint'leri kapsamalıdır.

Hard-Coded String Kullanmak

Hard-coded text translator workflow'u dışında kalır. Coverage metric onu göremez. Pseudo-locale ekranda kolayca fark eder. Lint yeni string eklenmesini engelleyebilir. Migration shared component'lerden başlatılabilir.

Cümleleri Parçalayıp Birleştirmek

Kelime sırası target language'de değişebilir. Grammar ve plural relation kaybolur. Translator bütün sentence context'ini göremez. ICU full-message yaklaşımı daha güvenlidir. Tekrarı azaltmak uğruna linguistic doğruluk feda edilmemelidir.

Pluralization'ı İngilizceye Göre Kodlamak

count === 1 global rule değildir. Birden fazla plural category kullanan locale'ler vardır. CLDR tabanlı formatter kullanılmalıdır. Translator locale-specific branch'leri yönetir. Test representative numeric values kapsar.

Locale ile Language'i Aynı Sanmak

Language yalnızca doğal dili ifade eder. Locale region veya script bilgisi taşıyabilir. Market yine ayrı business concept'tir. Bu ayrım currency ve legal selection hatalarını önler. Data model alan isimleri farkı açıkça göstermelidir.

Currency'yi Locale'den Otomatik Çıkarmak

Locale transaction currency'yi garanti etmez. Aynı kullanıcı farklı currency invoice görebilir. Money model explicit currency code taşır. Locale display formatting sağlar. Billing contract authoritative source'tur.

Accept-Language'i Kesin Kullanıcı Tercihi Sanmak

Browser header yalnızca tahmindir. Shared ve managed device'larda yanlış olabilir. User switch daha güçlü sinyaldir. Preference persist edilmelidir. Header first-visit convenience için kullanılabilir.

Bayrakları Dil Seçici Olarak Kullanmak

Flag country'yi temsil eder. Language birden fazla country'de kullanılabilir. Native language name daha açık label sağlar. Market selector ayrı control olabilir. Accessibility text label zorunlu tutulmalıdır.

RTL'yi Sonradan Düşünmek

LTR-only CSS application büyüdükçe düzeltme maliyeti artar. Logical properties başlangıçtan kullanılabilir. Design system pseudo-RTL story'leri taşıyabilir. Icon metadata direction behavior'ı merkezileştirir. İlk RTL locale rollout daha kolay olur.

Tüm Translation Bundle'larını Başlangıçta Yüklemek

Kullanıcı kullanmadığı language resource'ları indirir. Initial JavaScript ve parse cost artar. Active locale ve namespace loading daha verimlidir. CDN cache switch navigation'ı hızlandırır. Performance budget translation asset'lerini de kapsamalıdır.

Translator'a Context Vermemek

Short source string çoğu zaman ambiguous'dir. Screenshot ve description quality'yi artırır. Placeholder meaning açıklanmalıdır. User journey tone seçiminde yardımcı olur. Context defect prevention'ın en düşük maliyetli yöntemlerinden biridir.

Legal String'lerde Otomatik Fallback Kullanmak

Wrong market legal text riskli sonuç doğurabilir. Approved exact locale requirement belirlenmelidir. Missing translation feature rollout'u bloke edebilir. Version ve audit trail saklanır. Generic default chain legal content'ten ayrı yönetilir.

Sadece Ana Dili Accessibility Testinden Geçirmek

Translated ARIA label yanlış veya eksik olabilir. RTL focus order değişebilir. Long text button hit area'yı bozabilir. Screen reader pronunciation root lang'e bağlıdır. Tier 1 locale accessibility matrix içinde yer almalıdır.

Kurumsal i18n Maturity Model

i18n maturity modeli kurumun yalnızca kaç dil desteklediğini değil süreçlerin ne kadar güvenilir olduğunu gösterir. Hard-coded tek dilden translation key seviyesine geçiş ilk adımdır. Formatting, TMS ve CI kalite kapıları sistemi giderek daha sürdürülebilir hale getirir. Tenant override ve enterprise governance daha gelişmiş ihtiyaçları kapsar. En yüksek seviyede localization KPI ve SLO'lar normal product development'ın ayrılmaz parçası olur.

Seviye 0 — Hard-Coded Tek Dil

Bütün UI string'leri source code içindedir. Locale-aware formatter bulunmayabilir. Yeni language talebi geniş refactoring gerektirir. Translation operasyonu tanımlı değildir. İlk hedef string inventory ve shared formatter oluşturmaktır.

Seviye 1 — Translation Keys

Kullanıcı metinleri resource bundle'a taşınmıştır. Semantic key standardı oluşmaya başlar. Basic locale provider bulunur. Formatting hâlâ bazı ekranlarda manual olabilir. CI unknown veya missing key için temel kontrol ekleyebilir.

Seviye 2 — Locale-Aware Formatting + Fallback

Date, number ve currency standard formatter kullanır. Locale resolver deterministic hale gelir. Fallback chain tanımlıdır. Language switch preference persist eder. RTL henüz tam desteklenmeyebilir.

Seviye 3 — TMS + Continuous Localization

Developer key'leri otomatik TMS'e sync edilir. Translator ve reviewer workflow'u tanımlıdır. Translation memory ve glossary kullanılır. Approved artifact staging'e otomatik gelir. Lead time ölçülmeye başlanır.

Seviye 4 — RTL + Visual QA + CI Quality Gates

Design system logical CSS ve RTL stories taşır. Pseudo-localization CI içinde çalışır. ICU syntax ve placeholder gate zorunludur. Visual regression locale matrix'i bulunur. Translation quality release engineering'in resmi parçasıdır.

Seviye 5 — Enterprise Governance + Tenant Overrides

Locale tier ve quality SLA tanımlıdır. Legal string ayrı governance kullanır. Tenant-specific override versionlanır. Security access ve audit log standard hale gelir. Multi-team ownership modeli yazılıdır.

Seviye 6 — KPI, SLO ve Global-First Product Development

Yeni feature başlangıçtan locale-ready tasarlanır. Translation freshness ve fallback rate SLO ile izlenir. Locale bazlı task success ve support rate product kararlarını etkiler. Global market ihtiyaçları roadmap planning'in doğal girdisidir. Kurumsal Web Uygulamalarında Dil Zenginleştirme (i18n) artık ayrı bir localization projesi değil ürün platformunun sürekli yeteneğidir.

Sık Sorulan Sorular

Kurumsal i18n projelerinde en çok sorulan sorular terminology, locale seçimi, routing, SEO ve translation operasyonu çevresinde toplanır. Tek bir library bütün bu alanları çözmez. İyi sonuç standard web ve Unicode kurallarını product-specific governance ile birleştirmekten gelir. Aşağıdaki yanıtlar teknik ve operasyonel kararların temelini kısa biçimde özetler. Daha ayrıntılı uygulamada her kurum kendi market, security ve release gereksinimlerini ayrıca değerlendirmelidir.

i18n nedir?

i18n bir yazılımı birden fazla language, locale ve regional formatı destekleyebilecek şekilde hazırlama sürecidir. Translation bunun yalnızca bir bölümüdür. Routing, formatter, RTL ve backend notification gibi katmanları da kapsar. Amaç yeni locale eklenmesini büyük source code rewrite'ına dönüştürmemektir. Bu nedenle i18n temel olarak bir mühendislik ve ürün mimarisi konusudur.

l10n nedir?

l10n localization kelimesinin yaygın kısaltmasıdır. Internationalized ürünün belirli locale veya market için uyarlanmasını ifade eder. Translation, local terminology ve cultural review bu sürece dahildir. Engineering altyapısı l10n sürecinin uygulanmasını mümkün kılar. Her locale kendi QA ve approval gereksinimine sahip olabilir.

i18n ile localization arasındaki fark nedir?

i18n ürünün farklı locale'lere hazır hale getirilmesidir. Localization bu altyapı üzerinde belirli target locale'in gerçek uyarlamasını yapar. Birincisi ağırlıklı olarak engineering concern, ikincisi language ve market operasyonudur. İki ekip ortak message contract üzerinden çalışır. Sağlam i18n olmadan localization her yeni language'de tekrar teknik sorunlarla karşılaşır.

Locale nedir?

Locale language ve gerektiğinde region veya script gibi tercihleri temsil eden identifier'dır. en-US buna örnektir. Locale currency veya time zone ile aynı kavram değildir. Formatting ve translation resource seçimi için kullanılabilir. BCP 47 uyumlu identifier tercih edilmelidir.

tr ile tr-TR arasındaki fark nedir?

tr generic Turkish language tag'idir. tr-TR Türkiye region bağlamını ayrıca belirtir. Region-specific fark yoksa generic language yeterli olabilir. Legal veya market content Türkiye'ye özgüyse daha spesifik locale anlamlı olabilir. Gereksiz region ayrımı translation operasyonunu büyütür.

BCP 47 nedir?

BCP 47 internet ve web dünyasında language tag biçimini tanımlayan standard sistemdir. Language, script, region ve variant gibi subtag yapıları içerir. HTML lang ve birçok locale API bu modele dayanır. Application özel locale kodlarını uydurmak yerine standard tag kullanmalıdır. Valid subtag'ler IANA registry üzerinden doğrulanabilir.

ICU MessageFormat nedir?

ICU MessageFormat dynamic ve grammar-aware mesajların ifade edilmesine yardımcı olan message pattern yaklaşımıdır. Placeholder, plural ve select gibi yapılar sunar. Translator tam sentence branch'lerini target grammar'a göre düzenleyebilir. Count logic application code'a hard-code edilmez. Message syntax CI ile validate edilmelidir.

Pluralization nasıl yapılır?

Pluralization locale'in standard plural rules sistemi üzerinden yapılmalıdır. count === 1 yalnızca belirli dil varsayımını temsil eder. ICU plural category'leri target locale'e göre doğru branch'i seçer. Translator gerekli message biçimlerini sağlar. Test zero, one ve diğer representative count değerlerini kapsamalıdır.

Çok dilli web uygulamasında dil nasıl seçilir?

Önerilen model explicit URL veya user preference gibi güçlü sinyalleri önce değerlendirir. Tenant default ve cookie sonraki fallback kaynaklarıdır. Accept-Language yalnızca ilk tahmin olarak kullanılabilir. Sonuç supported locale listesine match edilir. Kullanıcıya her zaman language switch ile override imkanı verilmelidir.

Accept-Language nedir?

Accept-Language HTTP request'te browser'ın tercih edilen language aralıklarını bildiren header'dır. Server initial locale tahmininde kullanabilir. Bu değer kesin kullanıcı tercihi değildir. Shared veya managed device'da farklı olabilir. Explicit user selection daha yüksek öncelik taşımalıdır.

Dil seçimi cookie'de mi URL'de mi tutulmalıdır?

Public multilingual site için URL locale'i shareability ve SEO açısından güçlü source of truth sağlar. Cookie kullanıcı tercihinin hatırlanmasına yardımcı olabilir. İki yaklaşım birlikte kullanılabilir. URL explicit locale taşıyorsa cookie'den daha yüksek priority alabilir. Internal application SEO gerektirmiyorsa architecture farklı seçim yapabilir.

RTL desteği nasıl eklenir?

Root document direction ve language doğru set edilmelidir. CSS logical properties left/right bağımlılığını azaltır. Directional icon'lar merkezi metadata ile mirror edilebilir. Bidi user content isolation ayrıca ele alınmalıdır. Pseudo-RTL ve gerçek RTL locale visual QA yapılmalıdır.

CSS logical properties nedir?

Logical properties fiziksel sol ve sağ yerine inline başlangıç ve bitiş yönlerini kullanır. margin-inline-start buna örnektir. LTR ve RTL direction değiştiğinde aynı CSS uygun fiziksel tarafa uygulanabilir. Design system migration maliyetini azaltır. Fiziksel yön gerçekten anlamlı olduğunda left/right yine kullanılabilir.

Translation Management System nedir?

TMS translation operasyonunu developer source catalog ile translator workflow'u arasında yönetir. Translation memory, glossary, context ve review özellikleri sunabilir. API veya CLI continuous localization sağlar. Approved resource versionlanabilir. Kurumsal kullanımda security ve audit özellikleri ayrıca önemlidir.

Pseudo-localization nedir?

Pseudo-localization source mesajı test amacıyla yapay biçimde değiştirir. Text expansion ve accent character kullanımını simüle edebilir. Hard-coded string'leri görünür hale getirir. Gerçek translation gelmeden layout QA yapılmasını sağlar. Pseudo-RTL direction sorunları için ayrı variation olarak kullanılabilir.

Translation'lar CI/CD'ye nasıl bağlanır?

CI yeni key ve message syntax'ını doğrular. Source catalog TMS'e otomatik sync edilir. Approved target artifact staging'e alınır. QA sonrası version production'a promote edilir. Missing key, placeholder ve rollback kontrolleri release gate'in parçası olur.

Çok dilli web sitesi SEO'su nasıl yapılır?

Her locale için ayrı crawl edilebilir URL kullanılmalıdır. Hreflang alternate relation'ları doğru üretilir. Localized title, description ve sitemap hazırlanır. Canonical localized content modeliyle uyumlu olmalıdır. Browser language redirect'i crawler'ın diğer locale URL'lerine erişimini engellememelidir.

hreflang nedir?

hreflang aynı content'in farklı language veya region URL'lerini ilişkilendirmeye yardımcı olan alternate annotation'dır. Her page kendi URL'sini ve diğer varyantları listeler. Relation karşılıklı olmalıdır. x-default neutral fallback page için kullanılabilir. Invalid locale code veya broken URL otomatik test edilmelidir.

AI ile translation güvenli midir?

Machine-assisted translation düşük riskli content için hız sağlayabilir. Ancak context, terminology ve legal meaning hataları human review gerektirir. PII modele gönderilmemelidir. High-risk content machine-only publish edilmemelidir. Quality gate ve audit hangi translation'ın nasıl üretildiğini görünür tutmalıdır.

Backend e-postaları nasıl lokalize edilir?

E-mail job user veya organization locale'ini resolve etmelidir. Template translation resource veya TMS catalog kullanır. Date ve currency backend formatter üzerinden locale-aware üretilir. HTML direction ve font coverage hedef locale'e uygun olmalıdır. Legal footer exact market content resolution kullanabilir.

Multi-tenant uygulamalarda müşteri bazlı translation nasıl yapılır?

Global base translation üzerine tenant-specific locale override katmanı eklenebilir. Resolution en spesifik override'dan base locale'e ve default'a ilerler. Base source değiştiğinde stale override tespit edilmelidir. Admin edit ve publish audit edilmelidir. Security veya legal key'ler override'a kapalı tutulabilir.

i18n uygulama performansını etkiler mi?

Yanlış bundle stratejisi bütün locale resource'larını kullanıcıya gönderirse performans etkilenebilir. Active locale ve namespace lazy loading daha verimlidir. Formatter instance'ları uygun yerde reuse edilebilir. Translation CDN ve HTTP cache network latency'yi azaltır. Performance gerçek navigation ve bundle metric'leriyle ölçülmelidir.

Kurumsal web uygulamalarında i18n (Internationalization) yapısı nasıl kurulmalıdır?

Kurumsal yapı translation key, locale resolver, formatter, TMS, CI ve monitoring katmanlarını birbirinden ayırarak kurulmalıdır. Frontend ile backend aynı locale taxonomy'sini kullanmalı fakat business logic'i language'den bağımsız tutmalıdır. URL, user preference ve tenant default için deterministic resolution sırası belirlenmelidir. Runtime validation, missing translation telemetry ve legal content governance production kalitesini korur. Kurumsal web uygulaması i18n ve çoklu dil entegrasyon hizmeti planlanırken yalnızca framework seçimine değil bu bütünsel veri akışına odaklanmak gerekir.

i18n ile l10n (Localization) arasındaki fark nedir ve kurumsal projelerde nasıl birlikte yönetilir?

i18n farklı locale'lerin teknik olarak desteklenebilmesini sağlayan mühendislik temelidir. l10n ise bu temel üzerinde belirli dil ve market için gerçek uyarlama işidir. Engineering message contract, routing ve formatter'ı yönetirken localization ekibi linguistic quality ve terminology üzerinde çalışır. TMS ile CI iki ekibin ortak entegrasyon katmanı olabilir. Ownership bu şekilde ayrıldığında translation değişikliği source code düzenleme ihtiyacına dönüşmez.

Çoklu dil desteğinde çeviri dosyaları dil anahtarları tarih para birimi ve sayı formatları nasıl standartlaştırılmalıdır?

Translation key'leri semantic ve feature-scoped standard izlemelidir. Date, number ve currency translation string içine gömülmemeli, locale-aware formatter ile üretilmelidir. Currency explicit business value olarak taşınmalı ve locale'den otomatik çıkarılmamalıdır. Resource namespace'leri ownership ve lazy loading sınırlarına göre bölünmelidir. Kurumsal uygulamalarda çeviri dosyaları locale routing tarih para birimi ve dil yönetimi aynı governance çatısında tanımlanırsa ekranlar arasında davranış farkı ciddi ölçüde azalır.

Kurumsal web uygulamalarında dil seçimi hreflang URL yapısı ve çok dilli SEO nasıl yönetilmelidir?

Public content için locale-specific URL kullanmak en anlaşılır başlangıçlardan biridir. Hreflang her page'in kendisini ve karşılıklı alternate URL'lerini göstermelidir. User explicit locale selection browser tahmininden güçlü olmalıdır. Localized sitemap, metadata ve canonical strategy aynı URL taxonomy'sini kullanmalıdır. SEO crawler'larının bütün locale URL'lerini direct olarak açabilmesi sağlanmalıdır.

Kurumsal web uygulamalarında i18n ve çoklu dil entegrasyonu konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

i18n ve çok dilli web geliştirme danışmanlığı yakınımda şeklinde araştırma yaparken yalnızca translation hizmeti değil frontend, backend, routing, SEO ve CI süreçlerini birlikte değerlendirebilen teknik yaklaşım aramak faydalıdır. Diyarbakır Yazılım Topluluğu'nun çalışma alanları ve topluluk yaklaşımı hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alınabilir. Güncel proje çalışmalarını incelemek için https://www.diyarbakiryazilim.com.tr/projects adresi kullanılabilir. Eğitim veya danışmanlık görüşmesinde locale architecture, translation workflow ve production kalite kapılarının birlikte ele alınması önemlidir. Böylece yalnızca ilk dili ekleyen değil sonraki locale'lerin maliyetini de azaltan bir altyapı hedeflenebilir.

Sonuç: Kurumsal i18n Nasıl Sürdürülebilir Hale Getirilir?

Kurumsal i18n sürdürülebilir olduğunda yeni language eklemek haftalar süren manuel source code değişikliklerine dönüşmez. Language, locale, market, currency ve time zone ayrı kavramlar olarak doğru yerde modellenir. Translation workflow development pipeline ile birlikte ilerler. RTL, SEO, accessibility, legal content ve backend notification ilk architecture kararlarının parçası olur. Bu yaklaşım Kurumsal Web Uygulamalarında Dil Zenginleştirme (i18n) çalışmalarını kısa süreli çeviri projesinden global ürün yeteneğine dönüştürür.

i18n'i Çeviri Projesi Değil Ürün Mimarisi Olarak Ele Alın

Çeviri dosyası yalnızca görünen içerik katmanıdır. Asıl sistem locale resolution, formatting, routing ve content ownership üzerine kurulur. Product roadmap yeni locale requirement'ını feature architecture ile birlikte ele almalıdır. Platform ekibi ortak library ve CI standardını sağlar. Böylece her ekip aynı problemleri tekrar çözmek zorunda kalmaz.

Language, Locale, Region ve Currency Kavramlarını Ayırın

Bu kavramları tek language field içinde toplamak ileride yanlış business kararları üretir. Locale formatting bağlamıdır. Market commercial ve legal context taşır. Currency transaction'ın açık property'sidir. Data modelde ayrım yapılması sistemin yeni ülke ve sözleşmelere uyumunu kolaylaştırır.

Kullanıcıya Gösterilen Metni Koddan Ayırın

Hard-coded string localization workflow'unun dışında kalır. Semantic key ve resource bundle translator'ı source code'dan ayırır. Full-message yaklaşımı grammar özgürlüğü sağlar. Placeholder contract CI ile korunabilir. Kaynak content değişikliği translation history ile izlenebilir.

ICU/CLDR Tabanlı Dil Kurallarını Kullanın

Plural ve number kurallarını elle kodlamak yeni locale'lerde hata üretir. ICU ve CLDR tabanlı araçlar standard linguistic data kullanır. Formatter locale'e göre category ve presentation seçer. Developer yalnızca business value sağlar. Böylece dil kuralları application if statement'larına dağılmaz.

Locale Resolution'ı Deterministik ve Kullanıcı Tarafından Override Edilebilir Yapın

URL ve explicit user preference en güçlü kaynaklar arasında tutulmalıdır. Tenant, cookie ve browser header daha düşük priority'de çalışabilir. Resolver server ve client'ta aynı sonucu üretmelidir. User language switch her zaman erişilebilir kalmalıdır. Preference persistence automatic detection'ın kullanıcı iradesinin önüne geçmesini engeller.

RTL ve Text Expansion'ı Design System Seviyesinde Çözün

Logical CSS ve flexible components yeni locale rollout maliyetini azaltır. Pseudo-RTL gerçek translation olmadan engineering QA sağlar. Long-text story fixed width sorunlarını erken yakalar. Directional icon policy merkezi tutulur. Feature ekibi her component için yeniden RTL hack'i yazmak zorunda kalmaz.

Backend, E-mail, PDF ve Notification Katmanlarını da i18n Kapsamına Alın

Kullanıcı deneyimi browser ekranında bitmez. Notification job locale'i doğru resolve etmelidir. PDF renderer Unicode font ve RTL behavior'ını desteklemelidir. Backend machine code ile display message'ı ayırmalıdır. Bütün kanal terminology'si ortak glossary üzerinden yönetilebilir.

Translation Workflow'u CI/CD ile Otomatikleştirin

Developer key eklediğinde sync otomatik başlamalıdır. CI syntax ve placeholder contract'ını doğrular. TMS review approved artifact üretir. Staging QA sonrası production promotion yapılır. Versioning ve rollback localization change'lerini normal software release kadar izlenebilir hale getirir.

Legal, PII ve Enterprise Tenant İçeriği İçin Ayrı Governance Uygulayın

Her translation aynı risk seviyesine sahip değildir. Legal content exact market approval gerektirir. PII TMS ve machine translation sistemlerine gereksiz gönderilmemelidir. Tenant override source version değişikliklerinde stale olarak işaretlenebilir. Audit trail ve least privilege kurumsal localization supply chain'ini korur.

i18n'i “Daha Fazla Dil Dosyası Eklemek” Değil Global Ölçekte Sürdürülebilir Bir Ürün Yeteneği Olarak Yönetin

Başarılı internationalization, yeni locale eklemek için kaynak kodu tekrar tekrar yeniden tasarlama ihtiyacını azaltır. Maturity model, fallback metric ve translation freshness gibi göstergeler bu yeteneğin gelişimini ölçer. Ekipler routing, formatter, localization workflow ve design system üzerinde ortak standard kurduğunda yeni pazarların teknik maliyeti daha öngörülebilir hale gelir. Çok dilli mimari, frontend ve açık kaynak yazılım çalışmaları hakkında Diyarbakır Yazılım Topluluğu ile bağlantı kurmak için https://www.diyarbakiryazilim.com.tr/ adresini ziyaret edebilirsiniz. Kurumsal web uygulamalarında sürdürülebilir locale yönetimi kurmak, yalnızca bugünkü çeviri ihtiyacını değil ürünün gelecekteki büyümesini de güvence altına alan uzun vadeli bir mühendislik yatırımıdır.