Unicode normalization considerations/pt-br

O que é isso?
Desde a versão 1.4, o MediaWiki aplica a forma de normalização C (NFC) às entradas de texto em Unicode. Há boas razões para se fazer esta normalização:


 * Evitar conflitos entre títulos de páginas que, tendo os mesmos caracteres, têm estruturas de composição diferentes
 * Um problema persistente eram os arquivos multimédia importados do Safari; os nomes destes ficheiros, e portanto também os nomes das páginas correspondentes, estavam na forma decomposta enquanto a maioria das restantes ferramentas fornecem texto na forma composta


 * Permitir que a pesquisa funcione como esperado, independentemente da forma de composição da entrada textual

A forma C foi escolhida porque:


 * a vasta maioria dos dados de entrada já está na forma C e usa caracteres precompostos


 * é suposto que a forma C não envolva grandes perdas (que seja relativamente lossless), sendo que as únicas alterações são transformações invisíveis entre o carácter de base e a combinação de sequências de caracteres e de caracteres precompostos. Em teoria, a aparência do texto nunca é alterada porque foi normalizada para a forma C.


 * e adicionalmente, a W3C recomenda-a

O problema
No entanto, com a passagem do tempo surgiram alguns problemas.


 * Alguns marcadores de vogais combinadas em árabe, persa e hebraico são ordenados incorretamente
 * Alguns destes casos resultam de defeitos nas fontes ou nos compositores e só afetam algumas plataformas.
 * No entanto, alguns casos podem produzir texto incorreto, porque as classificações definidas não incluem distinções suficientes para produzir ordenações semanticamente corretas. Isto afeta sobretudo textos antigos, como o hebraico bíblico.


 * Uma exclusão de composições surpreendente, em Bangla.
 * O resultado não é composto corretamente por algumas ferramentas, provavelmente também devido a um defeito específico da respetiva plataforma.
 * Aparentemente, algumas ferramentas de pesquisa externas não sabem fazer a normalização e não encontram os textos normalizados na forma C.

Os problemas de composição e pesquisa são aborrecidos, embora, se mantivermos a nossa altivez, podemos tentar ignorá-los e deixar que as entidades externas corrijam o seu software defeituoso ao longo do tempo.

Os problemas de ordenação canônica são mais difíceis; seguindo as especificações atuais é simplesmente impossível ordenar corretamente. O Unicode não vai alterar as definições de ordenação porque isso iria contra as suas regras de compatibilidade, por isso, a menos que introduzam caracteres *novos* com o valor correto... De qualquer forma, não é certo que isto vá acontecer.

O que é que podemos fazer?
Podemos ignorar o problema e esperar que ele desapareça (o que é fácil, mas envolve lidar com as queixas contínuas de grupos linguísticos específicos), ou podemos desistir da normalização completa e alterar a forma como a usamos, para maximizar os benefícios e minimizar os problemas.

Se considerarmos a forma de normalização C (NFC) destrutiva (embora menos do que a forma relacionada NFKC) um plano de actuação possível é o seguinte:


 * Remover a verificação de normalização de todos os inputs da internet; substitui-mo-la por uma verificação mais limitada de validação UTF-8 mas permitimos que as formas de composição esquisitas passem sem alteração.


 * Aplicar a NFC diretamente nos sítios onde ela é mais necessária:
 * normalização dos títulos de páginas em Title::secureAndSplit
 * geração do índice para motores de pesquisa
 * Consultas sobre mecanismos de pesquisa

Esta abordagem é pouco invasiva, permitindo que o texto das páginas contenha formas de composição arbitrárias ao mesmo tempo que garantimos que os links e a pesquisa interna funcionam. Não exige alterações ao formato da base de dados e pode ser ativada sem interrupção de serviço.

No entanto, deixa os títulos visíveis das páginas na forma normalizada e potencialmente incorreta.

Longo prazo
Outra possibilidade seria permitir que os títulos das páginas fossem apresentados de formas não normalizadas. Isto pode ser feito em articulação com a permissão de formas arbitrárias do uso de maiúsculas ('iMonkey' em vez de '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.