Onde estão as traduções?

Depois de explicar que uma grande parte do planeta não fala inglês, então explicando como contribuir para a distribuição do Fedora, vamos ver onde estão as traduções de um software.

As traduções são parte integrante do código

Traduções são arquivos que são parte integrante do código-fonte necessário para executar o programa. O formato do arquivo contendo as traduções varia dependendo das ferramentas utilizadas pela equipe de desenvolvimento. Para ter uma ideia dos principais formatos de arquivo, a lista de formatos suportados pela plataforma de tradução Weblate é interessante. Em termos gerais, o formato Gettext é o mais usado para software compilado/desktop, e os formatos Json para software web. Cada arquivo tem suas vantagens e desvantagens, isso se enquadra no âmbito da internacionalização de software, frequentemente abreviado como i18n.

O impacto no trabalho de tradução

Como as traduções fazem parte do código-fonte, os tradutores devem entregar seu trabalho no prazo para que todas as alterações feitas na versão atual sejam traduzidas. Mesmo a menor alteração, mesmo de uma letra ou caractere, exige que cada tradução seja verificada para ver se a alteração afeta o significado ou a estrutura da frase; as alterações são caras para os tradutores.

Na maioria das vezes, e isso é normal, os desenvolvedores não sabem como adaptar as traduções ao fazer alterações. Portanto, é necessário que os tradutores acompanhem de perto o desenvolvimento do projeto para serem responsivos e evitar que a nova versão do projeto chegue aos usuários com uma sequência exibida em inglês no meio de um software que já foi parcialmente traduzido.

É aqui que a coisa fica complicada: existem pelo menos milhares de projetos de software livre, se não centenas de milhares. Existem milhares de idiomas. Será que podemos ter tradutores suficientes em cada idioma para acompanhar todos esses projetos? Certamente que não.

Processo de integração de tradução

Vamos agora pegar alguns projetos de exemplo para ver como a interação entre os processos de desenvolvimento de software e tradução é organizada.

Traduzível… mas arcaico!

Jitsi Meet é um software de videoconferência online. Em seu código-fonte, uma pasta lang contém um arquivo json por idioma.

Cada tradução deve estar sujeita a uma solicitação de integração, o que é complicado e demorado.

Em poucos minutos, encontro um caso extremo, essa solicitação que está esperando há mais de 8 meses. Entretanto, nesse meio tempo, o arquivo contendo as strings a serem traduzidas do software já foi alterado 19 vezes e há 8 versões lançadas !

Não há informações no readme sobre como traduzir, nem no guia de contribuição.

Comunidades linguísticas com muitas pessoas podem conseguir gastar o tempo necessário graças ao número de colaboradores (e mesmo assim…), todos os outros serão deixados de lado e o software oferecerá apenas traduções atualizadas de línguas que já estão super-representadas. Para acompanhar as mudanças, você provavelmente precisará assinar para ser notificado de alterações do projeto no GitHub.

A eficiência dessa forma de trabalhar é questionável. Embora possamos aplaudir o esforço para viabilizar a tradução do software, lamento a falta de consideração por esse tipo de contribuição. Não participei de discussões com as equipes do Jitsi Meet; nem sempre foi assim; uma plataforma de tradução já foi utilizada no passado.

Claro… mas muito específico do GNOME

O projeto GNOME utiliza uma versão semelhante, mas focada nas necessidades das equipes de tradução. Para enviar uma tradução para o software final, é obrigatório o uso do Git. No entanto, uma ferramenta está disponível para os tradutores, permitindo que eles saibam precisamente o que precisa ser traduzido e colaborem. Além disso, uma longa lista de softwares no ecossistema GNOME segue o mesmo cronograma de lançamento e fluxos de trabalho. O processo é, portanto, imperfeito e manual, mas as ferramentas reduzem significativamente os custos de gerenciamento para os colaboradores.

Eficaz… mas muito específico da Mozilla

O projeto Mozilla considera a tradução uma área-chave de sua atividade. Se você quiser contribuir, pode visitar a plataforma de tradução Pontoon (o projeto é organizado em equipes de tradução).

Saber o que pode ser traduzido é simples, e encontrar os contatos certos para tirar dúvidas também.

Este é um projeto enorme, e você pode ter alguma dificuldade para entender as etapas entre a plataforma de tradução e as versões do software, mas isso não é um problema. Tudo funciona bem: os cronogramas de lançamento são conhecidos e as prioridades já estão definidas. Pode levar um tempo para organizar uma equipe e estabelecer processos de revisão, e as ferramentas são específicas dos projetos da Mozilla, mas no geral tudo é bastante eficiente.

Automatizado e genérico, uma modernidade que liberta

É possível fornecer uma ferramenta dedicada às atividades de tradução, permitir o cancelamento em caso de alterações, o trabalho adicional e a prevenção da detecção de anomalias.

E, como bônus final, você terá uma sincronização automática com o código-fonte do software.

Um excelente exemplo: a plataforma de tradução Weblate define o padrão, tudo está conectado e automatizado. Há inúmeras alterações de tradução, e as alterações que as afetam são fáceis de encontrar.

Muitos projetos utilizam o Weblate; é a escolha ideal, independentemente do contexto. No ecossistema de plataformas de tradução, o Weblate tornou-se tão óbvio e eficiente quanto o Git para o gerenciamento de código-fonte no desenvolvimento de software.

Se o seu projeto oferece essa plataforma, você proporciona poder às contribuições linguísticas e, ao cultivar o relacionamento com essa grande comunidade, terá boas chances de obter uma ferramenta traduzida para vários idiomas.

Conclusão

A ligação entre os aspetos técnicos do projeto e as traduções é crucial para a eficiência dos processos de tradução.

Existem ferramentas repletas de recursos interessantes e automação para facilitar a vida de todos.

Cabe às equipes de desenvolvimento assumirem o controle disso, para que o software contenha cada vez mais traduções e um número crescente de idiomas seja suportado.

Mas o que acontece quando um projeto não lança novas versões? Como podemos compensar um projeto inativo? Este será o tema de um artigo futuro.