Considerações sobre a normalização Unicode

From MediaWiki.org
Jump to navigation Jump to search
This page is a translated version of the page Unicode normalization considerations and the translation is 100% complete.
Other languages:
English • ‎dansk • ‎español • ‎português • ‎português do Brasil • ‎русский • ‎日本語 • ‎한국어

O que é a normalização Unicode?

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 ficheiros 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.

O problema

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

  • 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 directamente 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
    • ocnsultas dos motores 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 fincionam. Não exige alterações ao formato da base de dados e pode ser activada sem interrupção de serviço.

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

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 seleccionar 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 efectuar 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