Uluslararasılaştırma ve yerelleştirme

Bilgi işlemde, uluslararasılaştırma ve yerelleştirme, genellikle i18n(internationalization) ve L10n(localization) olarak kısaltılır, bilgisayar yazılımını farklı dillere, bölgesel özelliklere ve bir hedef yerel ayarın teknik gereksinimlerine uyarlamanın araçlarıdır. Uluslararasılaştırma, bir yazılım uygulamasının mühendislik değişiklikleri olmaksızın çeşitli dillere ve bölgelere uyarlanabilmesi için tasarlama sürecidir. Yerelleştirme, metni çevirerek ve yerel ayara özel bileşenler ekleyerek uluslararasılaştırılmış yazılımı belirli bir bölge veya dile uyarlama sürecidir. Yerelleştirme (potansiyel olarak farklı yerel ayarlar için birden çok kez gerçekleştirilir), uluslararasılaştırmanın sağladığı altyapıyı veya esnekliği kullanır (ideal olarak yerelleştirmeden önce yalnızca bir kez veya devam eden geliştirmenin ayrılmaz bir parçası olarak gerçekleştirilir).

Terimler sıklıkla i18n numeronimiyle kısaltılır (burada 18, 1970'lerde veya 1980'lerde Digital Equipment Corporation'da ortaya atılan bir kullanım olan "internationalization" sözcüğündeki ilk i ile son n arasındaki harf sayısını ifade eder) ve kelimelerin uzunluğundan dolayı localization, L10n şeklinde kısaltılır. Bazı yazarlar, ikisini ayırt etmeye yardımcı olmak için ikinci kısaltmayı büyük harfle yazmıştır.

Microsoft, uluslararasılaştırmayı dünyaya hazır olma ve yerelleştirmenin bir birleşimi olarak tanımlar. Dünyaya hazır olma, bir ürünün birden çok komut dosyası ve kültürle kullanılmasını (küreselleşme) ve kullanıcı arabirimi kaynaklarını yerelleştirilebilir bir biçimde ayırmasını (yerelleştirilebilirlik(localizability), L12y olarak kısaltılır) sağlayan bir geliştirici görevidir.

Software without frontiers'a göre, bir ürünü uluslararası hale getirirken göz önünde bulundurulması gereken tasarım unsurları "veri kodlama, veri ve dokümantasyon, yazılım yapımı, donanım cihaz desteği, kullanıcı etkileşimi"; tamamen uluslararasılaştırılmış bir ürünü sıfırdan oluştururken göz önünde bulundurulması gereken temel tasarım alanları "kullanıcı etkileşimi, algoritma tasarımı ve veri formatları, yazılım hizmetleri, dokümantasyon"dur.

Farklı yazı sistemlerindeki farklı "komut dosyaları" farklı karakterler kullanır - farklı bir harf, hece, logogram veya sembol seti. Modern sistemler, birçok farklı dili tek bir karakter kodlamasıyla temsil etmek için Unicode standardını kullanır.

Yazma yönü çoğu Avrupa dilinde soldan sağa, İbranice ve Arapça'da sağdan sola veya boustrophedon yazılarında her ikisinde de ve isteğe bağlı olarak bazı Asya dillerinde dikeydir.

Farklı dillerin, sayısal içeriği dinamik olarak görüntüleyen programları karmaşıklaştırabilecek farklı çoğullaştırma kuralları vardır. Diğer dilbilgisi kuralları da değişebilir, örneğin tamlama .

Klavye kısayolları, yalnızca yerelleştirilmekte olan klavye düzeni üzerindeki düğmeleri kullanabilir. Bir kısayol belirli bir dildeki bir kelimeye karşılık geliyorsa (örn. Ctrl-s İngilizce'de "kaydet" anlamına gelir), değiştirilmesi gerekebilir.

Çevrimiçi haritalar, hava durumu raporları veya ödeme hizmeti sağlayıcıları gibi belirli üçüncü taraf hizmetleri, dünya çapında aynı taşıyıcılardan veya hiç mevcut olmayabilir.

Zaman dilimleri dünya çapında farklılık gösterir ve bir ürün orijinal olarak yalnızca tek bir zaman dilimindeki insanlarla etkileşime girdiyse bu dikkate alınmalıdır. Uluslararasılaştırma için, UTC genellikle dahili olarak kullanılır ve ardından görüntüleme amacıyla yerel bir saat dilimine dönüştürülür.

Bir ürünü uluslararası hale getirmek için, ürünün öngörülebilir şekilde gireceği çeşitli pazarlara bakmak önemlidir. Sokak adresleri için alan uzunluğu, adres için benzersiz biçim, posta kodu alanını posta kodu olmayan ülkelere adreslemek için isteğe bağlı hale getirebilme veya eyaletleri olmayan ülkeler için eyalet alanı gibi ayrıntılar ve ayrıca yeni kaydın tanıtılması yerel yasalara bağlı akışlar, uluslararasılaştırmayı karmaşık bir proje haline getiren örneklerden sadece birkaçıdır. Daha geniş bir yaklaşım, örneğin iş süreci mantığının uyarlanması veya bireysel kültürel (davranışsal) yönlerin dahil edilmesi ile ilgili kültürel faktörleri hesaba katar.

Daha 1990'larda, Bull gibi şirketler tüm çeviri faaliyetleri için büyük ölçekte makine çevirisini (Systran) kullandılar: insan çevirmenler ön düzenlemeyi (girdiyi makine tarafından okunabilir hale getirme) ve son düzenlemeyi ele aldılar.

Hem mevcut bir yazılımı yeniden tasarlarken hem de yeni bir uluslararasılaştırılmış yazılım tasarlarken, uluslararasılaştırmanın ilk adımı, potansiyel olarak yerel ayara bağlı her bir parçayı (kod, metin veya veri) ayrı bir modüle bölmektir. Her modül daha sonra standart bir kitaplığa/bağımlılığa dayanabilir veya her yerel ayar için gerektiğinde bağımsız olarak değiştirilebilir.

Geçerli geçerli uygulama, uygulamaların gerektiğinde program yürütme sırasında yüklenen kaynak dizelerine metin yerleştirmesidir. Kaynak dosyalarında saklanan bu dizelerin çevrilmesi nispeten kolaydır. Programlar genellikle seçilen yerel ayar verilerine bağlı olarak kaynak kitaplıklarına başvurmak üzere oluşturulur.

Çevrilebilir ve çevrilmiş dizeler için depolama, dizelere mesaj adı verildiğinden bazen mesaj kataloğu olarak da adlandırılır. Katalog genellikle belirli bir yerelleştirme formatında bir dizi dosyadan ve söz konusu formatı işlemek için standart bir kitaplıktan oluşur. Buna yardımcı olan bir yazılım kitaplığı ve formatı gettext'tir .

Bu nedenle, birden çok dili destekleyecek bir uygulama elde etmek için uygulama, çalışma zamanında ilgili dil kaynak dosyasını seçecek şekilde tasarlanır. Veri girişi doğrulamasını yönetmek için gereken kod ve yerel ayara duyarlı diğer birçok veri türü de farklı yerel ayar gereksinimlerini desteklemelidir. Modern geliştirme sistemleri ve işletim sistemleri, bu türlerin uluslararası desteği için gelişmiş kitaplıklar içerir, ayrıca yukarıdaki Standart yerel ayar verilerine bakın.

Birçok yerelleştirme sorunu (örneğin yazma yönü, metin sıralama), yazılımda metin çevirisinden daha derin değişiklikler gerektirir. Örneğin, OpenOffice.org bunu derleme anahtarlarıyla başarır.

Geliştirme ekipleri, bir dereceye kadar (örneğin kalite güvencesi için), sürecin temel/merkezi aşamalarını yöneten ve daha sonra diğerlerini etkinleştiren birini içerir. Bu kişiler tipik olarak yabancı dilleri ve kültürleri anlar ve bazı teknik altyapıya sahiptir. Uzman teknik yazarların, yerelleştirme öğelerini dağıtmak ve test etmek için mühendislik kaynaklarıyla birlikte, potansiyel olarak karmaşık kavramlar için kültürel olarak uygun bir sözdizimi oluşturması gerekir.

Düzgün bir şekilde uluslararası hale getirildikten sonra, yazılım yerelleştirme için daha merkezi olmayan modellere güvenebilir: ücretsiz ve açık kaynaklı yazılımlar genellikle, bazen ekipler halinde organize edilen son kullanıcılar ve gönüllüler tarafından kendi kendine yerelleştirmeye dayanır. Örneğin KDE3 projesi 100'den fazla dile çevrildi; 270 dilde MediaWiki, 100'ü çoğunlukla tamamlandı.

Mevcut metni diğer dillere çevirirken, ürünün kullanım ömrü boyunca metinlerin paralel versiyonlarını korumak zordur. Örneğin, kullanıcıya görüntülenen bir mesaj değiştirilirse, çevrilen tüm sürümlerin değiştirilmesi gerekir.

Ticari bir ortamda, yerelleştirmenin avantajı daha fazla pazara erişimdir. 1980'lerin başında, Lotus 1-2-3, program kodunu ve metnini ayırmak iki yıl sürdü ve Avrupa'da Microsoft Multiplan üzerindeki pazar liderliğini kaybetti. MicroPro, Batı Almanya pazarı için Avusturyalı bir tercüman kullanmanın WordStar belgelerinin bir yöneticinin "olması gereken tonda" olmamasına neden olduğunu tespit etti.

Bununla birlikte, mühendisliğin çok ötesine geçen önemli maliyetler söz konusudur. Ayrıca, ticari operasyonlar, genellikle tamamen farklı para birimlerinde, düzenleyici ortamlarda ve vergi rejimlerinde satılan çok sayıda ayrı yerelleştirilmiş ürünün üretimini, depolanmasını ve dağıtımını yönetmek için uyum sağlamalıdır.

Son olarak, yerelleştirilmiş ürünler için müşterileri desteklemek için satış, pazarlama ve teknik destek de yeni dillerde kendi operasyonlarını kolaylaştırmalıdır. Özellikle nispeten küçük dil popülasyonları için, yerelleştirilmiş bir ürün sunmak asla ekonomik olarak uygun olmayabilir. Büyük dil popülasyonlarının belirli bir ürün için yerelleştirmeyi haklı çıkarabileceği ve bir ürünün iç yapısının yerelleştirmeye zaten izin verdiği durumlarda bile, belirli bir yazılım geliştiricisi veya yayıncısı, birden çok yerel ayarda çalışmakla ilişkili yardımcı işlevleri yönetmek için boyut ve karmaşıklıktan yoksun olabilir.