Unicode normalization considerations/pt

Considerações sobre a normalização Unicode

O que é a normalização Unicode?

Desde a versão 1.4, o MediaWiki aplica a forma de normalização C (NFC) aos inputs de texto Unicode. Há boas razões para 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 do input textual

A forma C foi escolhida porque:

• a vasta maioria dos dados de input já está na forma C e usa caracteres precompostos
• é suposto que a forma C não envolva grandes perdas (seja 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. Teoricamente, 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 e hebraico são ordenados incorrectamente
  • Alguns destes casos resultam de defeitos nas fontes ou nos compositores e só afectam algumas plataformas.
  • No entanto, alguns casos podem produzir texto incorrecto, porque as classificações definidas não incluem distinções suficientes para produzir ordenações semanticamente correctas. Isto afecta sobretudo textos antigos, como o hebraico bíblico.
• uma exclusão de composições surpreendente, em Bangla
  • O resultado não é composto correctamente por algumas ferramentas, provavelmente também devido a um defeito específico da respectiva 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 altivês, 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 actuais é simplesmente impossível ordenar correctamente. 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 correcto... 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

• 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)

Língua:	English  • Português