Como criar um site multilíngue com publicação contínua

Minha experiência

O software geralmente é traduzível, porque os desenvolvedores e as desenvolvedoras estão cientes da utilidade desse esforço.

Espera-se que seja utilizada uma plataforma de tradução de qualidade, como o Weblate, e que as alterações de software cheguem aos tradutores assim que forem implementadas, e que as traduções retornem ao repositório de forma eficiente.

O software é apenas a ponta do iceberg, a parte que usamos diretamente, mas sem as informações complementares para discuti-lo, é difícil divulgá-lo amplamente se toda a comunicação for em inglês. São necessárias explicações sobre o que o software faz, para que serve, como usá-lo e assim por diante.

Os sites, base da comunicação de um projeto, são frequentemente traduzíveis. As tecnologias utilizadas para criar esses sites são relativamente não padronizadas e influenciadas pelo desejo dos criadores de personalização para diversificar o conteúdo, o que é possível através de algumas tags HTML.

A documentação é um mundo à parte, com ferramentas que muitas vezes se originam em ecossistemas de desenvolvimento (documentação técnica) ou de colaboração (wikis). É raro que essas ferramentas ofereçam os pré-requisitos de internacionalização necessários para a colaboração. No entanto, o problema é muito semelhante ao de um site.

Por fim, as comunicações mais diretas, que vão desde alterações para uma nova versão até comunicações em redes sociais para promover as ferramentas, raramente são multilíngues.

Por que tão poucos sites são traduzíveis?

Para um bom nível de tradução, são necessárias funcionalidades de internacionalização de software que reduzam o esforço e a complexidade do desenvolvimento, além de um processo simplificado no qual os tradutores possam se integrar.

Pré-requisitos para internacionalizar um site:

1. apoiar a escrita da direita para a esquerda
2. publicar o conteúdo multilíngue sem precisar modificar links internos
3. permitir alterar o idioma em qualquer página
4. levar em consideração o cabeçalho Accept-Language para direcionar para o idioma correto
5. permitir qualquer idioma e tipo de escrita do mundo

Dito assim, parece algo amplo e impressionante, mas alguns padrões como o UTF-8, algumas tags HTML e ferramentas desenvolvidas para atender a essas necessidades tornam tudo bastante fácil.

As ferramentas que os desenvolvedores utilizam devem incluir recursos que facilitem esse processo; isso se chama internacionalização. Se uma ferramenta não tiver um exemplo multilíngue em sua documentação ou uma seção dedicada à internacionalização, fuja dela. Certamente haverá uma opção melhor; disso não há dúvida.

Pré-requisito para colaboração: os desenvolvedores devem estar familiarizados e ser capazes de usar as ferramentas que facilitam a vida dos tradutores.

• Um tradutor deve ser capaz de traduzir sem ter acesso a nenhum código-fonte ou repositório de software.
• Um tradutor deve poder adicionar seu próprio idioma sem precisar pedir permissão.
• Um tradutor deve poder modificar uma tradução sem pedir permissão.
• O tradutor deve poder ser notificado sobre quaisquer alterações que envolvam uma tradução.
• As traduções devem ser implementadas automaticamente, sem intervenção humana.
• A equipe de desenvolvimento deve ser facilmente contatável em caso de problemas (autonomia ≠ autossuficiência)

Escolher a ferramenta certa para geração de sites estáticos

Apenas ferramentas que geram sites a partir de arquivos serão consideradas aqui. Um site dinâmico representa um tipo muito específico de complexidade, desnecessária para a maioria dos projetos de software livre. Trata-se, inclusive, de uma complexidade desnecessária que pode ser eliminada para economizar em manutenção, custos e riscos de segurança.

Sem precisar de nenhum conhecimento especializado em desenvolvimento, vamos comparar essas três ferramentas:

• Hugo tem uma página sobre publicação multilíngue, é bem completa e oferece exemplos, o que é importante para este projeto ⇒ experimente <3
• Jekyll não possui uma página de internacionalização, a menos que você concorde em usar um plugin e aceite suas limitações de compatibilidade/soluções alternativas ⇒ fuja!
• Eleventy tem uma página sobre internacionalização, então parece possível, mas é muito manual e não inspira confiança ⇒ fuja!
• Pelican só gere a tradução de um artigo, não há página dedicada à internacionalização, um recurso rudimentar é insuficiente ⇒ fuja!
• Publii não tem uma página de internacionalização ⇒ fuja!

O raciocínio é simples: você quer um site estático pronto para uso que seja funcional em vários idiomas? Use o Hugo.

Isso não é uma crítica pessoal ao Pelican e ao Jekyll, mas além de terem menos recursos que o Hugo e exigirem apenas a modificação dos cabeçalhos dos arquivos a serem traduzidos, representam uma etapa trabalhosa no processo de automação. E esse é justamente o objetivo: automação em todos os lugares, exigindo o mínimo de trabalho possível! Alguns projetos conseguem internacionalizar sites com sucesso usando essas ferramentas, mas ao custo de mais esforço e provavelmente oferecendo menos recursos (por exemplo, URLs em inglês em vez de traduzidas).

Um estudo de caso - este blog

Para efetivamente realizar esse trabalho de automação com dados reais, aqui estão minhas especificações:

• Não devem ser feitas alterações aos artigos no idioma original
• Utilizar o Welate como plataforma de tradução
• Nenhuma configuração é necessária no Weblate para adicionar um novo artigo
• Nenhuma configuração é necessária no Hugo para adicionar um idioma
• Um processo de publicação totalmente automatizado

Os passos envolvidos são simples.

Encontrando uma organização de conteúdo satisfatória

• content/fr conterá todo o conteúdo do site
• l10n/ conterá todos os arquivos de tradução
• l10n/config conterá as strings a serem traduzidas relacionadas à tradução para o Hugo
• l10n/pot os modelos de tradução (arquivos POT)
• l10n/po/%lang% as traduções em cada idioma (arquivos PO)

O conversor de formato po4a converterá o conteúdo em modelos de tradução (arquivos POT).

Um script em Python chamará o polib para identificar idiomas com pelo menos um artigo traduzido em pelo menos 80% (percentagem de palavras do texto original traduzidas).

Outro script em Python atualizará a configuração do Hugo usando as poucas configurações a serem traduzidas (nome do blog, descrição do blog…).

É uma solução alternativa que funciona; várias coisas podem ser feitas para simplificar essa ferramenta. Use a configuração do po4a em vez de chamar seus subcomandos e remova a necessidade de usar o polib para ter apenas um único arquivo Python.

Por que não usar o suporte a Markdown do Weblate? O Weblate é uma plataforma de tradução; converter arquivos é uma função diferente. Ferramentas dedicadas fazem isso melhor do que o Weblate, e separar as responsabilidades reduz a dependência e, portanto, aumenta a autonomia para escalar o pipeline de automação. Um exemplo típico: po4a poderia ser substituído por outra ferramenta.

Resultado e lição

Nossa comunidade de software livre tem a capacidade de criar sites multilíngues com facilidade.

No entanto, há uma falta de documentação que explique como montar as ferramentas existentes para criar uma linha de produção completa.

Este artigo visa, portanto, preencher essa lacuna e incentivar a replicação desse mecanismo em projetos interessados.

As ferramentas certamente serão aprimoradas e simplificadas, armazenadas em um pequeno projeto dedicado que explica seu funcionamento para maximizar sua reutilização. Hoje, você pode encontrar os scripts no repositório git do site languages-in-floss.