Considerações sobre a normalização Unicode

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

• • A persistent problem was media files uploaded from Safari; the filenames, and thus the page titles, were in decomposed form, while most other tools provided text in composed form

• 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

MediaWiki doesn't apply any normalization to its output, for example cafe<nowiki/>́ becomes "café" (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 %E1%BD%B5.

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 as ligações 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').

Neste caso, a tabela página pode ser alterada para acrescentar uma forma de apresentação do título:

  page_title:         'IMonkey'
  page_display_title: 'iMonkey'

ou formas ainda mais assustadoras de conversão de maiúsculas:

  page_title:         'imonkey'
  page_display_title: 'iMonkey'

Os títulos canónico e de apresentação seriam sempre transformáveis entre si, para manter a pureza da essência wiki; deve ser sempre possível selecionar o título da página com o rato, copiá-lo para um [[link]] e esperar que funcione.

Este tipo de alterações podem causar mais intrusivas, requerendo alterações à estrutura da base de dados e possivelmente grandes movimentações de dados entre tabelas de uma forma para a outra, pode isso podemos evitá-la a menos que haja grandes benefícios.

Outras formas de normalização

A NFC foi escolhida originalmente porque é suposta não ter perdas semânticas, mas a experiência demonstra que isto não é tão verdadeiro como inicialmente era esperado.

Podemos considerar utilizar a NFKC, a forma de composição de compatibilidade, pelo menos para alguns fins. Tem perdas mais explícitas; as formas de compatibilidade são recomendadas para efetuar pesquisas, posto que fazem conversão de maiúsculas para caracteres adicionais, como os latinos simples e as letras latinas de "largura total".

Seria provavelmente apropriado usar a NFKC para construir o índice de pesquisa e para examinar o texto da pesquisa, de forma a obter correspondências adicionais das coisas esquisitas. No entanto, não tenho a certeza de que seja suficientemente seguro para os títulos das páginas; talvez com um título de apresentação mas, sem o título, provavelmente não.

A normalização e unicodificação podem ambas ser feitas por robôs. Embora ainda não haja conhecimento de um robô que "normailize", a função é possível. O robô "Curpsbot-unicodify" unicodificou vários artigos da Wikipédia e isto não deve ser desfeito.

Ver também

• Manual:pecl-intl

• bugzilla:2399 (com resposta de Ken Whistler, editor do Unicode 5.0)
• http://www.gossamer-threads.com/lists/wiki/wikitech/184440 (tópico "Unicode equivalence" da lista de divulgação)