Erros de transcrição no WordPress

Sim, existem erros tipográficos e de transcrição nos meus artigos postados no WordPress.

O engine do WordPress faz algumas modificações nos meus artigos, ele “transcreve” meus caracteres ASCII para caracteres de mesma aparência, porém incompatíveis com caracteres ascii.
Isso é um problema real quando peço ao leitor fazer uma modificação num arquivo de configuração do sistema, e ele pega um trecho do artigo e copia/cola para onde é importante.

Quer um exemplo? Muitas vezes sugerí que você executasse algo assim :

sudo apt-get -y --purge pacote-lixo

Mas se eu não interví na transcrição talvez você tenha visto/copia/colado e executado isso :

sudo apt-get -y –purge pacote-lixo

No exemplo acima, ele trocou -- por –, que quando foi executado no seu sistema provavelmente deu erro de sintaxe. Mas e quando essas alterações se dão em arquivos textos de configuração do sistema ? Aí a coisa fica muito pior porque erros dessa natureza tem como consequencia desde a não-funcionalidade pretendida como também deixar seu sistema instável ou inoperante. Num certo artigo, eu postei a seguinte alteração no /etc/init.d/mountdevsubfs.sh :

Encontre essas linhas e descomente-as retirando o “#” do inicio delas ficando assim :

#
# Magic to make /proc/bus/usb work
#
mkdir -p /dev/bus/usb/.usbfs
domount usbfs "" /dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644
ln -s .usbfs/devices /dev/bus/usb/devices
mount --rbind /dev/bus/usb /proc/bus/usb

Mas no artigo apareceria assim :

Encontre essas linhas e descomente-as retirando o “#” do inicio delas ficando assim :

#
# Magic to make /proc/bus/usb work
#
mkdir -p /dev/bus/usb/.usbfs
domount usbfs “”; /dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644
ln -s .usbfs/devices /dev/bus/usb/devices
mount –rbind /dev/bus/usb /proc/bus/usb

Se você não notou a diferença, eu explico, as "aspas" se tornam “aspas comerciais”, dois traços seguidos -- se torna isso –. No exemplo acima, se você copiou o texto publicado e colou por cima no seu arquivo de configuração, a funcionalidade das suas portas USB podem ter perdido sua funcionalidade.

Para evitar esse tipo de erro de transcrição de caracteres ASCII importantes no wordpress, eu sempre edito os artigos usando HTML puro e ando com essa tabela HEXADECIMAL de caracteres ASCII em HTML :

http://www.ime.usp.br/~glauber/html/acentos.htm

E os utilizo assim que for usar algum caractere importante. Imagina o trabalho que isso dá !
E toda vez que tenho que reeditar um artigo porque algum erro foi encontrado, o próprio WordPress em muitas oportunidades “corrige” minhas referencias hexadecimal HTML para “caracteres normais” e começa tudo de novo. Não é apenas uma questão de Search/Replace porque no caso das aspas eu as utilizo também em TAGs HTML e essas não podem ser convertidas para ASCII-HEXA-HTML de forma automática.

Por essa razão, toda vez que você encontrar “aspas” dentro dum artigo, esteja atento que provavelmente estou me referindo a essa "aspas" . Em programação e administração de servidores, aspas, traços, maior/menor que, crase, pipe, etc… são muito utilizados e dá um trabalhão refazê-los usando ASCII-HEXA-HTML. Por isso, peço a sua compreensão para quando houver erros dessa natureza então aponta-los.

Antigamente as tags [PRE] sempre mantinham o aspecto ASCII, mas depois de alguma atualização do WordPress isso se perdeu e todos os artigos anteriores tiveram a transcrição dos códigos ascii para ascii-ala-wordpress. Os artigos com maiores potenciais de erros eu simplesmente excluí porque não dava para prejudicar alguém deliberadamente depois que soube do problema. Já apontei esse problema para os desenvolvedores do WordPress e a solução que me deram foi usar a tabela ASCII-HEXA-HTML e editar em puro HTML, e isso eu venho fazendo desde então. Um dia talvez a tag [PRE] volte a funcionar conforme era antes (ou já voltou, mas nunca conferí), mas eu não posso arriscar usa-la porque se ela retornar a fazer a transcrição ascii ala-wordpress terei de excluir muito mais artigos do que foi da última vez.

Concluindo, não use o copiar/colar de modo desenfreado. Esteja atento ao uso de tipografias não-ASCII que talvez esteja colando dentro de arquivos importantes.

Um abraço a todos,

H.

  1. #1 por Hugo Doria em 12 \12\UTC junho \12\UTC 2008 - 18:12

    Opa hamacker,

    Eu também tenho este problema. É realmente um saco.

    Dá uma olhada no post abaixo. Talvez te ajude.

    http://simplesideias.com.br/wp-coders/

    Abraços.

  2. #2 por Evandro em 13 \13\UTC junho \13\UTC 2008 - 9:58

    cara, talvez se vc tentasse jogar o texto em algum arquivo e deixar o link para down. e deixar esses erros somente para mostrar a sintaxe do codigo

  3. #3 por Neto Cury em 13 \13\UTC junho \13\UTC 2008 - 15:33

    ACHO que se você desabilitar a opção (em Configurações > Escrever)
    O WordPress deve corrigir automaticamente XHTML aninhado de forma inválida
    ele deixará de fazer isso.
    Veja bem, eu disse ACHO hehehe
    Abração

  4. #4 por Agail Sanches em 26 \26\UTC junho \26\UTC 2008 - 7:46

    Tenho o mesmo problema e é muito irritante que descaso por parte do time do wordpress deveriamos fazer uma petição para arrumarem isso

  1. OpenSuse 11: Instale os Drivers 3D da ATI e nVidia com um clique! « Ninjitisu Dojo
%d blogueiros gostam disto: