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.

The rendering and third-party search problems are annoying, though if we stay on our high horse we can try to ignore it and let the other parties fix their broken software over time.

The canonical ordering problems are a harder issue; you simply can't get these right by following the current specs. Unicode won't change the ordering definitions because it would break their compatibility rules, so unless they introduce *new* characters with the correct values... Well, it's not clear this is going to happen.

What can we do about it?
We can either ignore it and hope it goes away (easy, but entails dealing with ongoing complaints from particular linguistic groups), or we can give up on comprehensive normalization and change how we use it to maximize the benefits while minimizing the problems.

If we consider normalization form C (NFC) to be destructive (though not as much as its evil little sister NFKC), one possible plan might look like this:


 * Remove the normalization check on all web input; replace it with a more limited check for UTF-8 validity but allow funny composition forms through, as is.
 * Apply NFC directly in the places where it's most needed:
 * Page title normalization in Title::secureAndSplit
 * Search engine index generation
 * Search engine queries

This is minimally invasive, allowing page text to contain arbitrary composition forms while ensuring that linking and internal search continue to work. It requires no database format changes, and could be switched on without service disruption.

However, it does leave visible page titles in the normalized, potentially ugly or incorrect form.

Longer term
A further possibility would be to allow page titles to be displayed in non-normalized forms. This might be done in concert with allowing arbitrary case forms ('iMonkey' instead of 'IMonkey').

In this case, the page table might be changed to include a display title form:

page_title:        'IMonkey' page_display_title: 'iMonkey'

or perhaps even scarier case-folded stuff:

page_title:        'imonkey' page_display_title: 'iMonkey'

The canonical and display titles would always be transformable to one another to maintain purity of wiki essence; you should be able to copy the title with your mouse and paste it into a link and expect it to work.

These kinds of changes could be more disruptive, requiring changes to the database structure and possibly massive swapping of data around in the tables from one form to another, so we might avoid it unless there are big benefits to be gained.

Other normalization forms
NFC was originally chosen because it's supposed to be semantically lossless, but experience has shown that that's not quite as true as we'd hoped.

We may then consider NFKC, the compatibility composition form, for at least some purposes. It's more explicitly lossy; the compatibility forms are recommended for performing searches since they fold additional characters such as plain latin and "full-width" latin letters.

It would likely be appropriate to use NFKC for building the search index and to run on search input to get some additional matches on funny stuff. I'm not sure if it's safe enough for page titles, though; perhaps with a display title, but probably not without.

Normalizaton and unicodification can both be done by bots. While no bot has yet been known to "normalize", the function is possible. The "Curpsbot-unicodify" bot has unicodified various articles on Wikipedia and this should not be undone.