Traduzindo seu Blog WordPress

Você não acha estranho um monte de termo em inglês no final de um post bacana em Português? Eu vou te mostrar porque isso acontece, e como você pode resolver esse pequeno problema no seu próprio blog ou site.

Você já achou um blog bacana, rico em conteúdo, cheio de coisa interessante, na sua língua pátria e quando chegou no final da página leu coisas como “3 comments” ou “posted by Rodrigão on feb-11“. Se você for parecido comigo, deve ter achado isso ridículo…

Bom, em geral isso acontece por falta de conhecimento ou mesmo preguiça de quem criou o site. Nesse mundo globalizado, de acesso livre pela internet, e constante troca de informações entre pessoas de vários países, as chances são muito altas de que ao criar seu blog você use um pedaço de software escrito em outro idioma. Perfeitamente normal, o próprio WordPress é 100% escrito em Inglês.

O ruim acontece quando, por omissão ou preguiça, pequenos ajustes não são feitos. E quando esse pedaço de software não ajustado ocorre de ser um Tema WordPress, ou o plugin principal do seu blog, o resultado é seu usuário final vendo mensagens em outro idioma que não o mesmo do site.

Isso é ruim de várias formas! Primeiro, frusta o usuário que não fala aquele idioma (ou ao menos pode confundi-lo). Segundo, os buscadores enxergam essa palavras mal colocadas como falhas, e ninguém vai me convencer que esse não é um dos sinais de posicionamento (tudo bem que um bem fraquinho).

Mas então, como fazer para corrigir esse problema, sem encher o desenvolvedor de golpes mortais na cabeça?

[embedyt] http://www.youtube.com/watch?v=lTfGVZw64ds[/embedyt]

Escrevendo código localizável

Bom, vai depender um pouco. Em primeiro lugar, é preciso saber que existe uma certa “etiqueta” para se escrever código compatível com WordPress. Quero dizer, existe um “jeito certo” de se escrever temas, plugins e outras coisas para chamá-las de compatíveis com o WordPress. E parte dessa etiqueta reza que toda sentença ou mensagem para o usuário final deve ser encapsulada por uma chamada ao sistema tradutor do WordPress, de modo que o integrador tenha a opção de traduzir tal mensagem para seu idioma, e também para que um pacote de tradução possa ser criado para seu software.

Um exemplo simples. Suponha um plugin que lide com formulário de contato, e que quando a mensagem é registrada com sucesso exiba uma mensagem de sucesso. Agora, digamos que o autor é australiano, e tenha escrito o seguinte código:

<?php
if ($form_status == 'success') echo "Yeah Mate! Message received.";
else echo "Something went wrong, mate!";

Esse código tem efeito direto no seu blog, afinal quando o usuário preencher o formulário e enviar, verá uma dessas duas mensagens. Se meu pai usasse tal formulário ia achar que deu tudo errado (e estaria certo 50% das vezes hehe). O que e etiqueta do WordPress diz sobre isso é que esse trecho de código deveria ser reescrito com chamadas ao núcleo de tradução do WordPress, que usa o GNU GetText, que por podemos resumir como uma série de sentenças agrupadas em domínio. Isso pode ser feito, por exemplo, da seguinte forma:

<?php
if ($form_status == 'success') _e("Yeah Mate! Message received.", 'contact-form');
else _e("Something went wrong, mate!", 'contact-form');

Este código faz exatamente a mesma coisa que o anterior, com a mesma mensagem inclusive, mas agora existe um domínio declarado (contact-form), no qual pelo menos duas sentenças estão declaradas. O GetText fornece meios de analisar o código fonte procurando por chamadas às funções _e() e __(), e assim criar um arquivo POT que é uma tabela-padrão das sentenças declaradas em um domínio. A partir desse arquivo POT, há ferramentas que permitem gerar um arquivo PO, que nada mais é que um arquivo texto parecido com isso aqui:


"PO-Revision-Date: 2016-03-20 21:19:43-0300\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
"X-Generator: GlotPress/1.0-alpha-1100\n"
"Project-Id-Version: Administration\n"
#: wp-content/inc/form.php:101
msgid "Yeah Mate! Message received."
msgstr ""
#: wp-content/inc/form.php:102
msgid "Something went wrong, mate!"
msgstr ""

Esse arquivo tem informações bem interessantes. Primeiro, ele é direcionado a um único idioma, logo podem existir vários arquivos PO em um projeto, um para cada idioma. Segundo, ele menciona os arquivos e linhas do código-fonte onde as chamadas foram feitas para cada sentença. Isso permite uma análise contextual da mensagem, caso seu objetivo não seja imediatamente claro. Por fim, note que há uma linha com o comando msgid, sempre seguida de uma com o comando msgstr. Isso é um par de tradução, sendo msgid a mensagem original no código-fonte, e msgstr a equivalente no idioma do arquivo. Olha que maravilha: uma simples reescrita no código permite a um desenvolvedor usar mensagens em seu próprio idioma (seja ele qual for) sem trabalho extra, e ao mesmo tempo permitir que outras pessoas as traduzam e tornem seu código ainda mais útil.

Mas será mesmo preciso lidar com esse arquivo PO maluco? Bom, sim, até certo ponto. O arquivo PO é crucial, porque dele podemos compilar um arquivo MO, que é o que de fato o WordPress (GetText na verdade) utiliza para a tradução. Existem ferramentas para se fazer isso, mas eu considero a mais útil de todas um plugin para WordPress chamado Loco Translate.

Traduzindo com o plugin Loco Translate

O Loco Translate lida com todos estes aspectos discutidos: leitura do POT, edição do PO e compilação do MO. E permite fazer tudo isso do próprio admin do WordPress, com retorno imediato inclusive (salve e veja a tradução aplicada na hora). Ele faz até mais um pouco: quando não há o arquivo POT disponível, ou quando ele está desatualizado (omissões, omissões…), o Loco consegue ele mesmo analisar o código-fonte e encontrar as chamadas, resultando assim numa tabela atualizada de tudo o que pode ser traduzido em um plugin ou tema qualquer. Ah! e ele ainda salva os arquivos no lugar certo, esperado pelo WordPress, para que tudo funcione. De fato, há pouquíssimas coisas nesse mundinho de traduções que o Loco não consegue fazer, e estas em geral são atreladas a códigos de baixa qualidade (i.e. códigos que não seguem a etiqueta do WordPress).

Como exemplo prático ilustrativo, e na verdade meio que o motivo que me deu a ideia desse artigo, considere esse meu blog mesmo. Quando o criei eu achei um tema legalzinho chamado Gravit. Ele me pareceu útil, mas está todo em inglês. Então eu ativei o plugin Loco Translate, e ele já enxergou o Gravit, no caso sem nenhuma tradução disponível e nem mesmo um arquivo POT criado. Ainda assim, o loco conseguiu analisar o código e encontrou 70 sentenças, que eu traduzi em poucos minutos e salvei. Na hora, meus posts e rodapé já estavam em Português!

Se o desenvolvedor fosse ainda um pouco mais caprichoso, teria usado as chamadas convenientes também na parte do Tema que lida com sua tela de Personalização. Assim, coisas como Global Options e Show Post Icons, que somente o administrador enxerga, poderiam também estar em bom Português.

Aspectos técnicos da tradução em WordPress

Para fechar esse assunto, acho conveniente explicar alguns termos, de forma bem rapidinha. Primeiro, o trabalho de tradução em si não é tão direto quanto se poderia pensar, e existem alguns nuances que valem a pena citar:

Internacionalização (Internacionalization ou i18n)
é o processo de transformação de um conteúdo escrito em um idioma para um equivalente escrito em outro. Compreende basicamente uma tradução literal ou mecânica num par de idiomas. É isso que geralmente se faz no WordPress. Ex: a frase “nothing was found” é traduzida literalmente como “nada foi encontrado”. Como se poderia prever, isso basta na maioria dos casos. Curiosidade: o termo i18n é muito usado por desenvolvedores, e é uma forma curta de escrever o palavrão (no sentido de palavra grande) internacionalization, que começa com i, termina com n e tem 18 letras no meio, logo i18n.
Localização (Localization ou l10n)
é o processo de adaptar um conteúdo para outra cultura, mais do que simplesmente outro idioma. Permite fazer ajustes na abordagem ou apresentação de forma que diferenças culturais possam ser ultrapassadas e o conhecimento possa ser de fato absorvido. É mais usado em níveis mais altos de internacionalização, por exemplo, em sites de multinacionais com presenças em países com idiomas variados. Ao invés de ter uma “cópia traduzida” do site original em cada idioma (típico i18n), é mais proveitoso para essa empresa ter uma “versão local” em cada país, cada uma no idioma certo e com notícias e conteúdos mais localizados, não necessariamente iguais aos disponíveis nos demais países.
Códigos de Idioma
são códigos normatizados pela ISO, com aplicação mundial, que designam as variantes de cada idioma, em geral associando-as aos países. Por exemplo, o idioma Português tem o código pt, mas como há vários países falando Português, cada um do seu jeito, usamos os códigos pt_BR para Português Brasileiro, pt_AO para o Angolano e pt_PT para o de Portugal. Isso permite ser muito mais preciso na tradução, evitando por exemplo usar as palavras Ecrã e Telemóvel no Brasil, que só entende Tela e Celular. Os arquivos PO e MO utilizados em geral seguem a nomenclatura dominio-xx_YY, ou seja, o domínio seguido do idioma no formato ISO.
Sentenças
são as unidades de informação traduzíveis, que na maioria dos casos são Strings. Quando a String é fixa, tudo é muito óbvio (como nos exemplos acima). Mas elas também podem ser bem complicadas, por exemplo envolvendo código HTML ou mesmo variáveis de substituição. Como exemplo, as 3 Strings abaixo são perfeitamente válidas, mas progressivamente mais complicadas de traduzir (isto é, mais propensas ao erro):

  • Hello World
  • Hello %1$s, my name is %2$s
  • Hello <strong>%1$s</strong>&rarr; my name is <a href=”%3$s” rel=”author”>%2$s</a>

Cabe ao desenvolvedor ter o critério de simplificar as sentenças sempre que possível, reduzindo os erros de tradução.

Domínios
são agrupamentos de sentenças pertencentes a um mesmo escopo no código-fonte, por exemplo, o mesmo plugin, módulo, tema ou outra coisa. Novamente, é o desenvolvedor quem determina os domínios, e pode inclusive optar por usar mais de um. Também é possível que um plugin tenha um domínio principal e outros secundários, oriundos de códigos de terceiro dos quais o plugin depende. Hoje em dia é muito comum os temas terem uma boa base de tradução, porém utilizarem algo como o Redux para gerenciar suas opções, sem contudo fornecer os domínios corretos para a tradução delas. O resultado é um tema bem traduzido na frente do site, e um admin todo em inglês (às vezes mal escrito, ainda por cima).
Arquivo POT
são como uma tabela matriz com tudo o que o domínio oferece para ser traduzido. Só existe um POT por domínio, e ele não contém nenhuma tradução, apenas os textos originais.
Arquivo PO
é a primeira derivação do POT original (embora possa existir sem um POT também), e representa a série de pares de tradução entre o idioma original e o idioma alvo. Não há nenhuma obrigação do idioma original ser o Inglês, isso é apenas o mais comum. Se você escreve códigos em espanhol, pode perfeitamente fornecer POT e PO com originais em espanhol: isso apenas exigirá que a tradução para Francês deverá ser feita por alguém que fale Espanhol e Francês.
Arquivo MO
é um arquivo-objeto compilado de um PO, e pode ser visto como um pequeno banco de dados com o mapeamento de cada sentença original no texto traduzido equivalente. O arquivo MO não deve ser editado manualmente, mas somente pelas ferramentas e compiladores apropriados.

Por fim, acho muito útil dar uma palavrinha sobre dois aspectos finais da tradução em WordPress: onde os arquivo PO/MO devem ficar, e quem deve ser responsável por eles. Estes dois aspectos estão intimamente ligados.

Primeiro, é muito mais conveniente para o usuário final do código (em geral, o dono do site) que as traduções sejam fornecidas junto com o código, mesmo que não tenha sido o autor quem as tenha criado. O WordPress faz isso, assim como alguns de seus plugins mais famosos: você instala o Woocommerce e ele simplesmente está no seu idioma. Para que isso ocorra, o arquivo MO deve ficar na pasta languages na raíz do plugin (ou tema). É lá que o WordPress irá procurar por ele, e embora outras configurações sejam possíveis, requerem ações extras. O nome do arquivo deve ser padronizado, no estilo dominio-xx_YY.mo, onde o domínio em geral é o nome do plugin.

Existe um segundo lugar muito importante, que é a pasta wp-content/languages do seu WordPress. Os arquivos MO nesta pasta tem maior prioridade do que os na pasta do plugin/tema, e isso permite que você sobrescreva a tradução de um tema ou plugin com sua própria versão. Alguns temas e plugins nem usam mais os arquivos, mas apenas fazem com que o WordPress os baixe para esta pasta caso não existam. O WooCommerce, por exemplo, trabalha assim, e é este o motivo pelo qual depois que você atualiza o plugin, recebe uma mensagem dele avisando que a tradução no seu idioma está desatualizada.

Pronto! Falei o que tinha pra falar sobre isso. Agora, se você meu amigo (ou amiga!) conseguir finalizar o trabalho de traduzir um tema, plugin ou outra coisa que lhe foi útil, dê o próximo passo e disponibilize a tradução para as outras pessoas. Isso em geral é fácil, basta entrar em contato com a equipe de desenvolvimento e enviar os arquivos PO/MO para eles. A maioria das equipes terá prazer em receber e ainda lhe dará uma linha de crédito no site ou página deles.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Isso Te Ajudou?

Se este texto te deu alguma luz para resolver um problema ou entender melhor algum conceito, eu fico feliz.

Quem sabe eu possa te ajudar com algo mais específico?

Rapidinho

Compartilhe!

Compartilhar no facebook
Compartilhar no twitter
Compartilhar no linkedin
Compartilhar no whatsapp

Nunca pare de aprender!

Veja alguns textos relacionados

Configuração de um VPS no Google Cloud

Parte 1 – Criação da Instância escrevo depois Parte 2 – Configuração da Instância Nesse ponto, quando o Google disser “OK”, o que nós temos?

Ebooks grátis de Janeiro

Se você tem um Amazon Kindle e um smartphone da Samsung, provavelmente tem acesso à versão Galaxy do App da Amazon. As funcionalidades são as