Unicode normalization considerations/tr

Bu nedir?
1.4'ten beri MediaWiki, Unicode metin girişine normalizasyon formu C (NFC) uygular. Normalleştirmek için iyi nedenler var:


 * Aynı karakterlere ancak farklı kompozisyon dağılımına sahip çakışan sayfa başlıklarından kaçının.
 * Kalıcı bir sorun, Safari'den yüklenen medya dosyalarıydı; dosya adları ve dolayısıyla sayfa başlıkları ayrıştırılmış biçimdeyken, diğer araçların çoğu metni oluşturulmuş biçimde sağladı
 * Metin girişinin kompozisyon biçiminden bağımsız olarak aramanın beklendiği gibi çalışmasına izin verin.

Form C seçildi çünkü:


 * Giriş verilerinin büyük çoğunluğu önceden oluşturulmuş karakterler kullanılarak zaten C biçimindedir.
 * Form C'nin nispeten kayıpsız olduğu varsayılır, tek değişiklik temel karakter + karakter dizilerini birleştiren ve önceden oluşturulmuş karakterler arasındaki görünmez dönüşümlerdir. Teorik olarak, metin C biçimine normalleştirildiği için hiçbir zaman görünüşünü değiştirmemelidir.
 * Dahası, W3C bunu önerir.

MediaWiki doesn't apply any normalization to its output, for example  becomes "cafe ́" (shows U+0065 U+0301 in a row, without precomposed characters like U+00E9 appearing).

When MediaWiki shows an internal link, the page title is also normalized to the form C – even if encoded with HTML entities, references, or most other workarounds which evade respective transformation in the source code. But no NFC transformation happens (as of MediaWiki 1.35.0) on characters embedded to the page title in percent encoding, such as.

Sorun
Ancak, zaman geçtikçe, birkaç sorun ortaya çıktı.


 * sesli işaretçileri birleştiren bazı Arapça, Farsça ve İbranice yanlış sıralanır.
 * Bunlardan bazıları hatalı yazı tipleri veya oluşturuculardır ve yalnızca bazı platformları etkiler.
 * Bununla birlikte, birkaç durum yanlış metin üretebilir, çünkü tanımlanmış sınıflandırmalar anlamsal olarak doğru sıralama üretmeye yetecek kadar ayrım içermemektedir. Bu, öncelikle İncil İbranice gibi eski metinleri etkiler.
 * Bangla'da şaşırtıcı bir kompozisyon dışlaması.
 * Sonuç, bazı araçlarla doğru şekilde oluşturulmuyor, muhtemelen yine platforma özgü bir hata
 * Görünüşe göre bazı üçüncü taraf arama araçları, metinleri nasıl normalleştireceklerini bilmiyor ve bu kadar normalleştirilmiş metinleri bulamıyor.

Oluşturma ve üçüncü taraf arama sorunları can sıkıcıdır, ancak yüksek atımızda kalırsak bunu görmezden gelebilir ve diğer tarafların zaman içinde bozuk yazılımlarını düzeltmelerine izin verebiliriz.

Kanonik sıralama sorunları daha zor bir konudur; mevcut özellikleri takip ederek bunları doğru yapamazsınız. Unicode, uyumluluk kurallarını ihlal edeceği için sıralama tanımlarını değiştirmez, bu yüzden doğru değerlere sahip *yeni* karakterler sunmazlarsa... Bunun olacağı açık değil.

Bununla ilgili ne yapabiliriz?
Ya onu görmezden gelebiliriz ve ortadan kalkmasını umabiliriz (kolay, ancak belirli dil gruplarından gelen devam eden şikayetlerle ilgilenmeyi gerektirir) ya da kapsamlı normalleştirmeden vazgeçebilir ve sorunları en aza indirirken faydaları en üst düzeye çıkarmak için onu nasıl kullandığımızı değiştirebiliriz.

C formunu (NFC) normalleştirmenin anlaşmazlık olduğunu düşünürsek (kötü küçük kardeşi NFKC kadar olmasa da), olası bir plan şöyle görünebilir:


 * Tüm web girişlerindeki normalleştirme kontrolünü kaldırın; UTF-8 geçerliliği için daha sınırlı bir kontrol ile değiştirin, ancak olduğu gibi komik kompozisyon biçimlerine izin verin.
 * NFC'yi doğrudan en çok ihtiyaç duyulan yerlere uygulayın:
 * Title::secureAndSplit içinde sayfa başlığı normalizasyonu
 * Arama motoru endeksi oluşturma
 * Arama motoru sorguları

Bu, minimum düzeyde invazivdir, sayfa metninin keyfi kompozisyon formları içermesine izin verirken, bağlantı oluşturma ve dahili aramanın çalışmaya devam etmesini sağlar. Veritabanı biçim değişikliği gerektirmez ve hizmet kesintisi olmadan açılabilir.

Ancak, görünür sayfa başlıklarını normalleştirilmiş, potansiyel olarak çirkin veya yanlış biçimde bırakır.

Daha uzun vadeli
Başka bir olasılık, sayfa başlıklarının normalize edilmemiş formlarda görüntülenmesine izin vermek olabilir. Bu, keyfi durum formlarına ("IMonkey" yerine "iMonkey") izin vererek uyumlu bir şekilde yapılabilir.

Bu durumda, sayfa tablosu bir ekran başlığı formu içerecek şekilde değiştirilebilir:

page_title:        'IMonkey' page_display_title: 'iMonkey'

ya da belki daha da korkutucu durum katlamalı şeyler:

page_title:        'imonkey' page_display_title: 'iMonkey'

Kanonik ve ekran başlıkları, viki özünün saflığını korumak için her zaman birbirine dönüştürülebilir; başlığı farenizle kopyalayıp bir bağlantı içine yapıştırabilmeli ve çalışmasını beklemelisiniz.

Bu tür değişiklikler daha anlaşmazlık olabilir, veritabanı yapısında değişiklikler ve muhtemelen tabloların etrafındaki verilerin bir formdan diğerine büyük ölçüde değiş tokuş edilmesini gerektirebilir, bu nedenle elde edilecek büyük faydalar yoksa bundan kaçınabiliriz.

Diğer normalleştirme formları
NFC başlangıçta semantik olarak kayıpsız olması gerektiği için seçildi, ancak deneyimler bunun umduğumuz kadar doğru olmadığını gösterdi.

Daha sonra, en azından bazı amaçlar için uyumluluk kompozisyon formu olan NFKC'yi düşünebiliriz. Daha açık bir şekilde kayıplı; düz latin ve "tam genişlikte" latin harfleri gibi ek karakterleri katladıkları için arama yapmak için uyumluluk formları önerilir.

Arama indeksini oluşturmak için NFKC'yi kullanmak ve komik şeyler üzerinde bazı ek eşleşmeler elde etmek için arama girdisini çalıştırmak muhtemelen uygun olacaktır. Yine de sayfa başlıkları için yeterince güvenli olup olmadığından emin değilim; belki bir ekran başlığıyla, ancak muhtemelen olmadan değil.

Normalleştirme ve unicodification botlar tarafından yapılabilir. Henüz hiçbir bot'un "normalleştirdiği" bilinmemekle birlikte, işlev mümkündür. "Curpsbot-unicodify" botu Vikipedi'deki çeşitli maddeleri birleştirdi ve bu geri alınmamalıdır.

Ayrıca bakınız

 * 2399 (Ken Whistler, Unicode 5.0 editörü yanıtıyla)
 * http://www.gossamer-threads.com/lists/wiki/wikitech/184440 ("Unicode eşdeğeri" posta listesi dizisi)