İçindekiler
i18n ve l10n: Uluslararasılaştırma ile Yerelleştirme Arasındaki Fark Nedir?
Küreselleşme sürecindeki bir projeye dahil olup birinin "i18n ve l10n yapmalıyız" dediğini duyduğunuzda, bu iki kavramın eş anlamlı mı, zıt mı yoksa farklı isimler taşıyan aynı şey mi olduğunu merak eden yalnız değilsiniz.
Hiçbiri değil. Uluslararasılaştırma ve yerelleştirme, belirli bir sırayla gerçekleşen, farklı ekipleri kapsayan ve farklı türde çıktılar üreten iki ayrı disiplindir. Bu ikisini birbirine karıştırmak — ya da yanlış sırayla uygulamak — bir ürün ekibinin yeni pazarlara girerken yapabileceği en maliyetli hatalardan biridir.
Bu makale her iki terimi açıkça ele alıyor, sektörün kullandığı ilgili terminolojiyi kapsıyor ve sürecin hem mühendislik hem de içerik tarafı için pratik kontrol listeleri sunuyor.
Özet / Temel Çıkarımlar
- i18n, uluslararasılaştırma anlamına gelir ("i" ile "n" arasında 18 harf vardır). Bir ürünü birden fazla dil ve bölgeyi desteklemeye hazır hale getiren mühendislik çalışmasıdır.
- l10n, yerelleştirme anlamına gelir ("l" ile "n" arasında 10 harf vardır). Bir ürünün belirli bir dil ve kültürde gerçekten işlevsel olmasını sağlayan içerik ve uyarlama çalışmasıdır.
- i18n tek seferlik bir mühendislik yatırımıdır; l10n ise her hedef yerel ayar için bir kez yapılan, tekrarlayan bir operasyonel süreçtir.
- i18n her zaman l10n'dan önce tamamlanmalıdır. Tersine yapmak, neredeyse her zaman ilk seferinde doğru yapılmasından daha pahalıya mal olan yeniden çalışmaya yol açar.
- Daha geniş kapsayıcı terim, hem i18n hem de l10n'u pazar stratejisiyle birlikte kapsayan g11n (küreselleştirme)'dir.
Uluslararasılaştırma (i18n) Nedir?
Uluslararasılaştırma, yeni bir yerel ayar eklendiğinde her seferinde kaynak kodunda değişiklik yapılmasına gerek kalmaksızın bir ürünün farklı dillere, bölgelere ve kültürel geleneklere uyarlanabilmesi için tasarlanması ve geliştirilmesi sürecidir.
i18n numeroniması kelimenin kendisinden gelir: "internationalization" kelimesinde ilk "i" ile son "n" arasında 18 harf bulunur. Tam kelimenin teknik belgelerde tekrar tekrar yazılması zahmetli hale geldiğinden, sektör bu kısaltmayı benimsedi. i18n ile "internationalisation" (İngiliz imlası) birbirinin yerine kullanılır — her ikisi de aynı mühendislik disiplinine atıfta bulunur.
Uluslararasılaştırma özünde teknik bir meseledir. Bu çalışmayı yapan kişiler yazılım mühendisleridir ve çıktı, üzerine çevirilerin yerleştirileceği temeli oluşturan kod, yapılandırma ve mimari kararlardan ibarettir.
i18n Mühendisliği Neler İçerir
Dize dışsallaştırma en temel adımdır. Düğme etiketleri, hata mesajları, araç ipuçları, e-posta konu satırları, bildirim metinleri gibi kullanıcıya yönelik tüm metinler kaynak koddan çıkarılarak kaynak dosyalarına (.json, .po, .resx veya .yaml gibi) taşınmalıdır. React bileşenindeki <button>Submit</button> gibi sabit kodlanmış bir dize, kaynak koduna dokunmadan çevrilemez. <button>{t('form.submit')}</button> gibi dışsallaştırılmış bir dize ise kaynak dosyası güncellenerek ve yeniden dağıtılarak çevrilebilir; kod değişikliği gerekmez.
Unicode ve karakter kodlaması, yığının her katmanında doğru şekilde ele alınmalıdır. W3C, tüm web içerikleri için Unicode standardındaki her alfabeyi kapsayan UTF-8 karakter kodlamasını güçlü bir şekilde önermektedir — Latin, Kiril, Arapça, CJK (Çince, Japonca, Korece) ve diğerleri. [^1] Verilerini Latin-1 gibi eski bir kodlamada saklayan bir ürün, kullanıcı Japonca bir isim veya Arapça bir adres girdiği anda karakterleri bozacaktır.
Tarih, saat, sayı ve para birimi biçimlendirmesi yerel ayarlar arasında büyük farklılıklar gösterir. "03/04/2026" tarihi Amerika Birleşik Devletleri'nde 4 Mart, Avrupa'nın büyük bölümünde ise 3 Nisan anlamına gelir. "1.000" sayısı Almanya'da bir bini, Amerika Birleşik Devletleri'nde ise onu (üç ondalık sıfırla) ifade eder. Unicode Common Locale Data Repository (CLDR), 900'den fazla yerel ayar için biçimlendirme kurallarını tanımlar. [^2] Uluslararasılaştırılmış bir ürün, biçim dizelerini elle oluşturmak yerine JavaScript'teki Intl.DateTimeFormat ve Intl.NumberFormat gibi yerel ayar tabanlı biçimlendirme işlevlerini kullanır.
Çoğullama kuralları diller arasında beklenmedik şekillerde farklılık gösterir. İngilizce'nin iki çoğul biçimi vardır (1 öğe, 2 öğe). Arapça'nın altı biçimi vardır. Rusça'nın üç biçimi vardır ve hangi sayılara hangi biçimin uygulandığına dair karmaşık kurallar mevcuttur. Bir i18n kütüphanesi, çeviri ekiplerinin her dil için doğru sayıda çoğul varyant sunabilmesi amacıyla CLDR çoğul kurallarını desteklemelidir.
Sağdan sola (RTL) düzen desteği, Arapça, İbranice, Farsça ve Urduca için gereklidir. Bu, kullanıcı arayüzünün ayna görüntüsü olması gerektiği anlamına gelir: navigasyon sağ tarafa geçer, metin hizalaması tersine döner, yön ima eden simgeler (oklar, breadcrumb'lar) ters çevrilir ve tarayıcının belge yön niteliğine göre düzeni otomatik olarak çevirebilmesi için CSS düzen özellikleri mantıksal değerler kullanmalıdır (margin-left yerine margin-inline-start).
Yerel ayar tabanlı yönlendirme, yerel ayar tanımlayıcılarının URL'lerde nasıl görüneceğini belirler. İki yaygın yaklaşım alt dizinler (better-i18n.com/fr/pricing) ve alt alanlardır (fr.better-i18n.com). W3C, yerel ayar tanımlaması için BCP 47'ye dayalı dil etiketlerinin kullanılmasını önermektedir (örn. en, en-US, pt-BR, zh-Hant). [^3] Yönlendirme katmanı kullanıcının tercih ettiği yerel ayarı tespit etmeli, doğru içeriği sunmalı ve arama motoru tarayıcıları için doğru Content-Language HTTP başlığını ve hreflang niteliklerini döndürmelidir.
Birleştirilmiş dize yok kuralı ayrı bir vurguyu hak ediyor. "Your order of " + count + " items has shipped" gibi bir birleştirme, hedef dildeki kelime sırası tamamen farklı olabileceğinden doğru şekilde çevrilemez. Uygun i18n, adlandırılmış yer tutuculu mesaj biçimi dizeleri kullanır: "Your order of {count} items has shipped" — burada çevirmen tam cümleyi alır ve yer tutucuyu hedef dilin gerektirdiği yere yerleştirebilir.
Yerelleştirme (l10n) Nedir?
Yerelleştirme, bir ürünün — metni, görselleri, tonu ve işlevselliği — belirli bir hedef yerel ayar için uyarlanması sürecidir. Uluslararasılaştırma kabı oluşturursa, yerelleştirme onu doldurur.
l10n numeroniması aynı kalıbı izler: "localization" kelimesinde "l" ile "n" arasında 10 harf bulunur.
Yerelleştirme öncelikle bir içerik ve kültürel meseledir. Bu çalışmayı yapan kişiler çevirmenler, yerelleştirme mühendisleri, kültürel danışmanlar ve hukuki denetçilerdir. Çıktı, yerel ayara özgü varlıklardır: çevrilmiş dize dosyaları, uyarlanmış görseller, bölgeye özgü hukuki metinler ve yerel ayarda test edilmiş derlemeler.
l10n İçerik Çalışması Neler İçerir
Çeviri, yerelleştirmenin en görünür parçasıdır. i18n sırasında dışsallaştırılan her dize hedef dile çevrilmelidir — kelime kelime değil, deyimsel olarak. İyi bir çeviri anlam, ton ve niyeti korur. Büyük dil modelleriyle makine çevirisi (MT) önemli ölçüde gelişmiştir, ancak pazarlama metinleri, hukuki içerikler ve marka sesinin önem taşıdığı metinler için profesyonel insan incelemesi önemini korumaktadır.
Kültürel uyarlama, kelimesi kelimesine çevirinin ötesine geçer. Görseller, renk kullanımı, mizah ve metaforların tümü kültürel ağırlık taşır. Baş parmak yukarı simgesi birçok Batı kültüründe olumlu bir anlam taşırken Orta Doğu'nun bazı bölgelerinde rahatsız edici kabul edilir. El sıkışmayı gösteren bir fotoğrafın, fiziksel temas normlarının farklı olduğu pazarlarda farklı bir jestle değiştirilmesi gerekebilir. Tarih örnekleri, isim biçimleri (ad-soyad sırası), adres biçimleri ve telefon numarası biçimleri hepsinin yerel ayara özgü işlem gerektirdiği alanlardır.
Hukuki ve düzenleyici uyum pazara göre değişir. AB, GDPR ve ePrivacy Direktifi kapsamında açık çerez onayı gerektirir. Brezilya'nın LGPD'si, Kaliforniya'nın CCPA'sı vardır. Vergi gösterimi kuralları, fiyat açıklama gereksinimleri ve zorunlu hukuki bildirimler yargı bölgelerine göre farklılık gösterir. Yerelleştirme ekipleri, hedef pazarlara göre bu gereksinimleri belirlemekten ve ürünün bunları karşılamasını sağlamaktan sorumludur.
Yerel ayara özgü test, çevrilmiş ürünün gerçekte doğru çalıştığını doğrular. Bu; çevrilmiş dizelerin kullanıcı arayüzü kaplarına sığdığının (Almanca dizeler genellikle İngilizce eşdeğerlerinden %30-40 daha uzundur), RTL düzenlerin doğru oluşturulduğunun, yerel ayara özgü tarih ve sayı biçimlerinin beklendiği gibi görüntülendiğinin ve yerel ayara özgü hukuki içeriklerin mevcut olduğunun kontrolünü içerir.
i18n ve l10n Karşılaştırma Tablosu
| Boyut | Uluslararasılaştırma (i18n) | Yerelleştirme (l10n) |
|---|---|---|
| Kim yapar | Yazılım mühendisleri | Çevirmenler, yerelleştirme mühendisleri, kültürel danışmanlar |
| Ne zaman gerçekleşir | Yerel ayara özgü herhangi bir çalışmadan önce; ürün başına bir kez | i18n tamamlandıktan sonra; hedef yerel ayar başına bir kez |
| Neler içerir | Dize dışsallaştırma, Unicode, biçimlendirme, RTL, yönlendirme | Çeviri, kültürel uyarlama, hukuki uyum, yerel ayar testi |
| Birincil çıktı | Kod, mimari, kaynak dosya yapısı | Çevrilmiş dize dosyaları, uyarlanmış varlıklar, yerel ayar derlemeleri |
| Kullanılan araçlar | i18n kütüphaneleri (next-intl, i18next, ICU), CLDR, Unicode | TMS platformları, CAT araçları, MT motorları, QA araçları |
| Maliyet profili | Sabit ön mühendislik maliyeti, bir kez ödenir | Her içerik güncellemesiyle tekrarlayan, yerel ayar başına maliyet |
| Geri alınabilirlik | Sonradan uyarlamak zordur | Güncellenmesi veya değiştirilmesi basittir |
| İş sürücüsü | Mühendislik hazırlığı | Pazara giriş ve gelir |
İlgili Terimler
i18n ve l10n alanı, aynı numeronima kalıbını izleyen bir kısaltma sözcük dağarcığı geliştirmiştir.
g11n — Küreselleştirme ("g" ile "n" arasında 11 harf), bir ürünün uluslararası pazarlarda kullanılabilir ve başarılı kılınması için gereken tüm çabayı kapsayan çatı terimidir. i18n ve l10n'u kapsar; ancak bunlara ek olarak pazar stratejisi, uluslararası fiyatlandırma, uluslararası hukuki yapı ve pazara giriş planlamasını da içerir. Bir şirket "küreselleşiyoruz" dediğinde, i18n ve l10n'un iki teknik bileşen olduğu bir g11n çabasını tanımlamaktadır.
t9n — Çeviri ("t" ile "n" arasında 9 harf), terimlerin en dardır. Çeviri, l10n'un bir alt kümesidir — özellikle metni kaynak dilden hedef dile dönüştürme eylemidir. Yerelleştirme çeviriyi kapsar; ancak yukarıda açıklanan metin dışı uyarlama çalışmasını da içerir. Bir ürün, tam olarak yerelleştirilmeden çevrilebilir (örn. metin Fransızcaya dönüştürülür, ancak tarih biçimleri hâlâ ABD biçiminde görünür ve görseller uyarlanmaz).
a11y — Erişilebilirlik ("a" ile "y" arasında 11 harf), ilgili ancak bağımsız bir disiplindir. Erişilebilirlik, görsel, motor, işitsel veya bilişsel engelli kişiler tarafından kullanılabilecek ürünler tasarlamayı ifade eder. i18n ile kesişim gerçektir: ekran okuyucuları çok dilli içeriği doğru şekilde işlemelidir, ARIA etiketleri görünür metinle birlikte çevrilmelidir ve RTL düzen değişiklikleri klavye navigasyonunu veya odak sırasını bozmamalıdır. Uluslararasılaştırılmış ürünler geliştiren ekipler, erişilebilirlik ve uluslararasılaştırmayı sıralı değil paralel gereksinimler olarak ele almalıdır.
GILT Çerçevesi, disiplinleri dört alana ayıran bir sektör çerçevesidir: Küreselleştirme, Uluslararasılaştırma, Yerelleştirme ve Çeviri. GILT, mühendislik hazırlığından pazara hazır içerik teslimine kadar olan tam tedarik zincirini tanımlamak için yerelleştirme sektöründe yaygın olarak kullanılmaktadır.
Doğru Sıra: Her Zaman Önce i18n, Sonra l10n
Bu bir tercih değil — zorunlu bir bağımlılıktır. Yerelleştirme, altında çalışan bir i18n altyapısı olmadan gerçekleşemez ve i18n tamamlanmadan l10n denemesi hızla birikim yapan isrfata yol açar.
Sırayı ters çevirdiğinizde neler yanlış gider:
Bir geliştirme ekibinin bir ürünü İngilizce olarak piyasaya sürdüğünü, ardından Alman pazarına girme kararı alındığında kod tabanını bir çeviri firmasına teslim ettiğini hayal edin. Çevirmen kodu açar ve JSX bileşenlerinde sabit kodlanmış İngilizce dizeler, yalnızca İngilizce alan değerleri döndüren SQL sorguları, her zaman MM/DD/YYYY çıktısı üreten bir tarih biçimlendirme yardımcı programı ve RTL değerlendirmesi yapılmadan margin-left ve text-align: left kullanan bir CSS düzeni bulur.
Çeviri firması bu kod tabanıyla yararlı hiçbir şey yapamaz. Mühendislik ekibi artık olgun bir üründe dize dışsallaştırmasını sonradan uyarlamak zorundadır — yüzlerce bileşene dokunmak, veritabanı şemalarını yeniden yapılandırmak, biçimlendirme yardımcı programlarını yeniden yazmak ve her düzeni RTL güvenliği açısından denetlemek gerekir. Bu uyarlama çalışması yalnızca eklemeli değildir; üretim sisteminde regresyonlara yol açma riski taşır. Alman lansmanı aylarca gecikir ve maliyet, baştan yapılacak i18n yatırımının katlarına ulaşır.
İkinci bir başarısızlık modu kısmi i18n'dir. Bir ekip ön uçta dizeleri dışsallaştırır ancak çoğullamayı doğru ele almayı unutur. Çevirmen Almanca çoğul biçimler sağlar, ancak mühendislik ekibi uygun bir mesaj biçimi yerine count + " Artikel" yazdığı için kod her zaman yalnızca tekil biçimi kullanır. Sonuç, o pazardaki her kullanıcının gördüğü üretimde dilbilgisel açıdan hatalı Almancadır.
Üçüncü bir başarısızlık modu, yönlendirme içselleştirilmeden önce eklenen yerel ayara özgü özelliklerdir. Bir ekip, uygun bir yerel ayar yönlendirme sistemi oluşturmadan /fr/ dizinini manuel olarak oluşturarak Fransızca bir blog bölümü ekler. Daha sonra İtalyanca eklemek istediklerinde yönlendirmeyi tamamen yeniden yapılandırmaları gerekir ve Fransızca URL'ler bozularak zaman içinde biriktirilen SEO sinyallerine zarar verebilir.
Pratik kural şudur: i18n bir ön koşuldur. Tek bir çeviri komisyonu vermeden önce yerel ayar yönlendirmenizi, dize dışsallaştırmanızı, biçimlendirme yardımcı programlarınızı ve çoğullama desteğinizi tanımlayın ve uygulayın. Altyapı bir kez yerleştiğinde, her yeni yerel ayar eklemek öngörülebilir ve sınırlı bir operasyona dönüşür.
Geliştiriciler için i18n Kontrol Listesi
Uluslararasılaştırma altyapısı oluştururken veya denetlerken bu kontrol listesini kullanın.
- Dize dışsallaştırma tamamlandı: Kullanıcıya yönelik her dize kaynak kodda sabit kodlanmış değil, bir kaynak dosyasında depolanmaktadır. Buna hata mesajları, doğrulama mesajları, e-posta şablonları ve meta etiketler dahildir.
- UTF-8 kodlaması uygulandı: Veritabanı sütunları UTF-8 (veya MySQL'de utf8mb4) kullanıyor, HTTP yanıtları
charset=utf-8bildiriyor ve dosya G/Ç işlemleri boyunca UTF-8 kullanılıyor. - Yerel ayar tabanlı tarih ve saat biçimlendirmesi: Tarihler ve saatler yerel ayar tabanlı işlevler (örn.
Intl.DateTimeFormat) kullanılarak biçimlendiriliyor ve UTC olarak depolanarak yerel ayar yalnızca görüntüleme katmanında uygulanıyor. - Yerel ayar tabanlı sayı ve para birimi biçimlendirmesi: Sayılar ve para birimi değerleri
Intl.NumberFormatveya eşdeğeri kullanılarak biçimlendiriliyor. Para birimi sembolleri sabit kodlanmış değil. - Çoğullama CLDR kuralları aracılığıyla ele alındı: i18n kütüphanesi CLDR çoğul kategorilerini (sıfır, bir, iki, az, çok, diğer) destekliyor ve çevirmenler her kategori için varyant sağlayabiliyor.
- Birleştirilmiş dize yok: Değişken içeren kullanıcıya yönelik tüm dizeler, tek bir çevrilebilir mesajda adlandırılmış yer tutucular kullanıyor. Çevrilmiş parçaları birleştirerek oluşturulan dize yok.
- RTL düzen desteği: CSS mantıksal özellikler kullanıyor.
dirniteliği<html>öğesinde dinamik olarak ayarlanıyor. UI bileşenleri RTL yerel ayarlarıyla test ediliyor. - Yerel ayar yönlendirmesi uygulandı: URL'ler tutarlı bir yerel ayar kuralını (örn.
/en/,/fr/) izliyor. Yönlendirme katmanı,Accept-Languagebaşlıklarından ve kullanıcı tercihlerinden yerel ayarı tespit edip müzakere ediyor. - hreflang etiketleri mevcut: Her sayfa,
x-defaultdahil tüm mevcut yerel ayar varyantları için<link rel="alternate" hreflang="...">etiketleri bildiriyor. - Yerel ayar tanımlayıcıları BCP 47'yi izliyor: Dil etiketleri özel veya tutarsız tanımlayıcılar yerine IETF BCP 47 biçimini kullanıyor (örn.
en-US,pt-BR,zh-Hant).
İçerik Ekipleri için l10n Kontrol Listesi
Yeni bir hedef yerel ayar için bir yerelleştirme projesi planlarken ve yürütürken bu kontrol listesini kullanın.
- Çeviri iş akışı oluşturuldu: Bir çeviri yönetim sistemi (TMS) veya yapılandırılmış inceleme süreci mevcut. Kaynak dizeler sürüm kontrollü ve değişiklik bildirimleri çeviri ekibine ulaşıyor.
- Çevirmen brifing tamamlandı: Çevirmenler bir stil kılavuzu, ürüne özgü terimler sözlüğü, ses tonu rehberliği ve her dize için bağlam (ekran görüntüleri veya hazırlık ortamı erişimi) aldı.
- Makine çevirisi insanlar tarafından incelendi: Makineyle çevrilen içerikler, özellikle pazarlama metinleri, hukuki metinler ve kullanıcıya yönelik hata mesajları için nitelikli bir insan çevirmen tarafından son düzenlemeye tabi tutuldu.
- Kültürel inceleme yapıldı: Görseller, renk seçimleri, simgeler ve örnekler, hedef pazarla ilgili kültürel bilgiye sahip biri tarafından incelendi. Potansiyel rahatsız edici veya kafa karıştırıcı unsurlar uyarlandı.
- Hukuki ve düzenleyici gereksinimler belirlendi: Ekip, hedef pazarda hangi gizlilik açıklamalarının, çerez bildirimlerinin, yasal uyarıların ve düzenleyici gereksinimlerin geçerli olduğunu belirledi ve yerel ayara özgü sürümler üretti.
- Dize uzunluğu UI'de test edildi: Çevrilmiş dizeler hedef yerel ayardaki gerçek UI'de incelendi. Kesme, taşma ve düzen bozulmaları tespit edildi ve çözüldü.
- Yerel ayara özgü biçimler doğrulandı: Tarihler, sayılar, adresler, telefon numaraları ve posta kodları hedef yerel ayardaki kullanıcıların beklediği biçimde görüntüleniyor.
- İşlevsel test tamamlandı: Ürün, hedef yerel ayarda uçtan uca test edildi — ödeme akışları, form doğrulama mesajları, e-posta bildirimleri ve yerel ayara özgü hukuki akışlar dahil.
SSS
i18n, çeviriyle aynı şey midir?
Hayır. Çeviri (t9n), yerelleştirmenin (l10n) bir alt kümesidir ve yerelleştirme, uluslararasılaştırmanın (i18n) tamamlanmasına bağlı olan aşağı akış bir faaliyettir. i18n, çeviriyi mümkün kılan mühendislik çalışmasıdır. Çeviri, metni bir dilden diğerine dönüştürme eylemidir. İkisi birbiriyle ilişkili ancak farklıdır — i18n altyapısı olmadan etkili bir şekilde çeviri yapamazsınız, ancak i18n'i tamamlamak herhangi bir çeviri yapıldığı anlamına gelmez.
Bir ürün, uluslararasılaştırılmış ancak yerelleştirilmemiş olabilir mi?
Evet ve bu yaygın bir ara durumdur. Dizelerini dışsallaştırmış, yerel ayar tabanlı yönlendirmeyi uygulamış ve RTL desteği oluşturmuş bir ürün tamamen uluslararasılaştırılmıştır — ancak çevrilmiş kaynak dosyaları oluşturulmamışsa yalnızca varsayılan yerel ayarda çalışır. Altyapı yerelleştirmeye hazırdır, ancak henüz yerelleştirme teslim edilmemiştir. Bu, çeviri çalışması komisyona vermeden önce bulunulması gereken doğru durumdur.
i18n ve l10n numeronimaları resmi bir statüye sahip midir?
Bunlar resmi standartlardan ziyade yaygın olarak benimsenmiş sektör gelenekleridir. W3C Uluslararasılaştırma Faaliyeti, yayımladığı özellikler ve çalışma grubu belgelerinde "i18n" kullanmaktadır. GILT çerçevesini geliştiren Yerelleştirme Sektörü Standartlar Birliği (LISA), feshedilmeden önce "l10n" terimini tutarlı biçimde kullanmıştır. Her iki terim de yazılım sektöründe evrensel olarak anlaşılmaktadır.
l10n ile kültürel uyarlama arasındaki fark nedir?
Kültürel uyarlama, ayrı bir disiplin değil l10n'un bir bileşenidir. Yerelleştirme; çeviri, kültürel uyarlama, hukuki uyum ve yerel ayara özgü testi kapsar. Bazı kuruluşlar, pazarlama içeriğinin hedef pazar için kelimenin tam anlamıyla çevrilmek yerine önemli ölçüde yeniden yazıldığı durumlarda "transkreasyon" terimini kullanır — bu, kaynak metnin gerçek bir şablon olmaktan ziyade niyet rehberi olarak hizmet ettiği yüksek çaba gerektiren bir kültürel uyarlama biçimidir.
i18n, SEO'yu nasıl etkiler?
Önemli ölçüde. Doğru uluslararasılaştırılmış bir site; arama motorlarına hangi URL'nin hangi dile ve bölgeye hizmet ettiğini söylemek için hreflang ek açıklamalarını kullanır, BCP 47 yerel ayar tanımlayıcılarını tutarlı biçimde kullanır, doğru Content-Language HTTP başlığını sunar ve her yerel ayarın kanonik bir URL'ye sahip olmasını sağlayarak yinelenen içerik sorunlarından kaçınır. Google'ın uluslararası hedefleme kılavuzu, her pazardaki kullanıcılara doğru yerel ayara özgü sayfayı sunmak için bu sinyallere dayanır. Yönlendirme veya hreflang yapılandırmasını hatalı yapan bir i18n uygulaması, arama sonuçlarında yanlış yerel ayarın sıralanmasına — ya da hiç sıralanmamasına — yol açabilir.
Sonuç
Uluslararasılaştırma ve yerelleştirme, birbirinin yerine kullanılabilir terimler değil tamamlayıcı disiplinlerdir. i18n teknik temeldir — dil ve yerel ayar endişelerini kaynak koddan çıkarıp yapılandırılabilir, değiştirilebilir kaynak dosyalarına taşıyan mühendislik çalışmasıdır. l10n ise bu temeli gerçek pazarlardaki gerçek kullanıcıların göreceği çevrilmiş, kültürel olarak uyarlanmış ve hukuki açıdan uyumlu içerikle dolduran içerik operasyonudur.
Sıra önemlidir: uluslararasılaştırma her zaman önce gelir. Altyapı bir kez kurulduktan sonra her yeni yerel ayar, mühendislik yeniden çalışmasının bir kaynağı olmak yerine sınırlı, tekrarlanabilir bir operasyona dönüşür.
Her iki tarafı da ayrı araçlarla yönetmeden uygulamak isteyen ekipler için Better i18n gibi platformlar, hem i18n altyapısını (SDK, yerel ayar yönlendirme) hem de l10n iş akışını (AI çevirisi, CDN dağıtımı) tek bir platformda sunarak mühendislik ve içerik tarafları arasındaki koordinasyon yükünü azaltır.
Küresel iddialara sahip yeni bir ürün mı geliştiriyorsunuz, yoksa mevcut bir ürünü yeni pazarlar için mi uyarlıyorsunuz — i18n ile l10n arasındaki farkı netleştirmek, her ikisini de iyi yapmanın ilk adımıdır.
Referanslar
[^1]: W3C Uluslararasılaştırma Çalışma Grubu. "Character encodings: Essential concepts." W3C. https://www.w3.org/International/articles/definitions-characters/
[^2]: Unicode Konsorsiyumu. "Common Locale Data Repository (CLDR)." Unicode. https://cldr.unicode.org/
[^3]: W3C Uluslararasılaştırma Çalışma Grubu. "Language tags in HTML and XML." W3C. https://www.w3.org/International/articles/language-tags/
[^4]: W3C Uluslararasılaştırma Çalışma Grubu. "Localization vs. Internationalization." W3C. https://www.w3.org/International/questions/qa-i18n
[^5]: Internet Engineering Task Force. "Tags for Identifying Languages (BCP 47)." IETF RFC 5646. https://www.rfc-editor.org/rfc/rfc5646
[^6]: Unicode Konsorsiyumu. "Plural Rules." Unicode CLDR. https://cldr.unicode.org/index/cldr-spec/plural-rules
