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.

Depois de algum tempo, o pessoal do WordPress criou a tag

 e 

onde os caracteres no intervalo da tag não sofrem nenhuma alteração de troca de caracteres, mas existe a alteração estética, por exemplo, não há quebra de página e as fontes viram fonte do tipo terminal na maioria dos temas. Em algumas oportunidades noto que entre

  e  

não pode haver linhas em branco, pois se houverem o [/code] é aplicado implicitamente no local da linha em branco.

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.