Tradução de temas e plugins
Depois de conversar com o @alvaro-gois-dos-santos e com @jose-freitas no #wclx15 e no slack, julgo que esta questão pode beneficiar dum debate mais alargado na comunidade.
Actualmente a tradução do core e dos projectos do WordPress está centralizada na página da equipa de tradução pt_PT do próprio WordPress.
A tradução de temas e plugins é naturalmente feita em contacto directo entre os respectivos autores e os tradutores, nas suas plataformas próprias. Cada um de nós que já traduziu um tema ou plugin, para fazer um bom trabalho, deverá conhecer o WordPress e a sua terminologia própria, comparando constantemente com os ficheiros de localização do próprio core (frontend e backend).
Penso que haverá um enorme benefício para as versões portuguesas de temas e plugins se este trabalho individual for cruzado e debatido. No caso dos temas parece-me que o benefício é mais limitado, mas no caso dos plugins, há muitos que são instalados por uma grande maioria de utilizadores portugueses.
Como fazer isto em comunidade?
No meu processo individual de tradução, sempre que possível utilizo o GitHub para manter os meus ficheiros de tradução sincronizados com o repositório do autor. Com alguma frequência é necessário corrigir um bug relativo à tradução, a falta dum textdomain, ou submeter uma outra qualquer alteração à própria string. O processo individual tem esta vantagem.
Em comunidade será bastante mais complexo manter uma base material a traduzir.
Deverá a comunidade fazer um fork do repositório completo ou manter apenas uma cópia sincronizada do catálogo .pot do repositório do autor? Por vezes nem um .pot existe ou não está actualizado, há situações em que só existem os respectivos ficheiros .po/.mo, ou pior ainda, alguns repositórios têm apenas disponíveis os ficheiros .mo obrigando a que o tradutor mantenha o seu próprio ficheiro master .po.
Há autores que delegam em comunidades do Transifex a tradução dos seus temas/plugins, o que torna demasiado frequente encontrar traduções feitas por profissionais, mas sem conhecimento das terminologias próprias adoptadas pelo WordPress em português, já para não mencionar traduções automatizadas via google.
Aquilo que penso ser viável é pensar no processo que cada um de nós já utiliza individualmente e traduzi-lo para a comunidade, deixando naturalmente de fora os processos de debug.
Seria possível manter um repositório de traduções da comunidade WP-Portugal, onde se poderiam incluir as traduções que já foram feitas por cada um de nós. A dificuldade poderá existir em manter sincronizado o tal .pot que por vezes não existe, mas também não é difícil de criar. Por fim, a tradução concluída poderia ser submetida ao autor do tema/plugin, com a validação da comunidade.
Na minha transposição do processo individual para a comunidade parece-me facil via GitHub, mas acrescento por sugestão do @alvaro-gois-dos-santos a possibilidade duma instalação GlotPress próprio da comunidade, onde se centralizaria este trabalho à imagem do que é feito no Polyglots do core como mencionado acima. Uma vantagem desta última sugestão é os tradutores não precisarem de qualquer conhecimento de Git, o que aumenta consideravelmente a quantidade de possíveis tradutores.
Não sendo programador, convido todos os que se interessem por este tema a pensar num processo de automatizar a sincronia destas traduções com os repositórios dos autores. Julgo que haverá forma de notificar a existência de novas strings para traduzir com algo como o GlotPress Notify.
Resumo do processo:
- Adicionar tema/plugin à plataforma
- Traduzir em comunidade
- Submeter/sincronizar com o repositório do autor
O convite à tradução de plugins e temas abre outras discussões periféricas, como a lista do que deve ser traduzido, os opensource vs comerciais, contrapartidas, a atribuição duma qualquer validação pela equipa de tradução da WP-Portugal, a manutenção manual ou automatizada do glossário, etc.
Embora eu prefira traduzir projectos por natureza abertos à comunidade, esta lista ou escolha de material a traduzir parece-me perfeitamente orgânica, os que reunirem mais interessados serão naturalmente os mais acompanhados pela comunidade de tradutores.
Sem que este tópico se sobreponha à tradução do próprio core, espero que este debate ajude a optimizar nosso esforço individual enquanto tradutores que mantêm alguns temas/plugins, para que este trabalho não se perca e todos ganhem.
Rui Cruz 5 Jun 2017, às 15:59 Permalink | Inicie a sessão para responder
Viva,
Por acaso estava mesmo a vir aqui…
Bom, acho que a questão é outra. Eu trabalhei com leitores de ecrã e a sua tradução – como o JAWS http://www.freedomscientific.com/Products/Blindness/JAWS – e lembro-me claramente de ser “ir para”.
Até porque as traduções do Office (Word, por exemplo) têm também Ir para.
Eu estava a fazer um debugging num site e desliguei imagens e css e só me apercebi disso por causa das coisas que “tirei”, caso contrário nem tinha reparado neste pormenor.
Acho mesmo que devíamos usar o Ir para. Just my 5 cents.
R.
Rui Cruz 5 Jun 2017, às 16:01 Permalink | Inicie a sessão para responder
Para referência, sobre o Office:
“Ir para a próxima região de marcos”
Fonte: https://support.office.com/pt-pt/article/Atalhos-de-teclado-no-Word-Online-4ccbb899-f71e-4206-be6f-1d30c7d1bd13
Álvaro Góis 5 Jun 2017, às 16:05 Permalink | Inicie a sessão para responder
Ir para a próxima região de marcos? Atalhos de teclado para utilizar o friso? Não sei se isto é grande referência de tradução Rui.
José Freitas 5 Jun 2017, às 17:19 Permalink | Inicie a sessão para responder
Creio que “ir para” parece-me mais lógico. Mas depende do contexto.
Vitor Madeira 5 Jun 2017, às 17:20 Permalink | Inicie a sessão para responder
O original seria “Skip to main content”?
Compreendo que a intenção original possa ser a de “saltar” um ou outro passo que possa ser sugerido antes de seguir para o “conteúdo principal” mas acho que até ficaria mais lógico que seja alterado para “Ir para o conteúdo principal.”
Numa outra perspetiva, provavelmente, ‘pular’ faria mais sentido se a intenção for a de manter o “salto”?
(Mas mesmo assim, continuo a supor existir mais lógica no “ir para”.)