Gostaria de mobilizar algumas pessoas que conheçam e possam contribuir para o GlotPress para conseguirmos resolver um problema que estamos a ter com as traduções portuguesas. Nos últimos meses houve duas alterações muito significativas na forma de gestão das traduções no WordPress. Por um lado, o WordPress passou a considerar variantes da língua para o mesmo locale, abrindo assim a possibilidade, p.e., a versões formais e informais. Mas, e no nosso caso isso é significativo, também a variantes ortográficas, como a do A090. Por outro lado, a integração de temas e plugins no GlotPress oficial do WordPress.org veio reforçar a necessidade de consolidação de termos e de minorar a mais que provável confusão que se vai instalando.
Quais são as opções neste momento? A primeira seria ter uma versão AO90 para o WordPress (core, temas e plugins). O problema é que isso iria criar necessariamente problemas de consolidação de termos e de desfasamento. Se é possível criar uma versão AO90 a partir da versão oficial (usando ferramentas offline), e foi isso que fizemos com o PT Variants, a verdade é que não existe ferramenta que faça o caminho inverso. Ou seja, quando tivermos o WordPress pt_PT também a obedecer ao AO90, serão duas versões autónomas, para as quais poderão existir contribuidores diferentes com formulações diferentes. O que é um problema sério, tanto para o resultado final como para a gestão de traduções, de editores e de validadores das traduções. A verdade é que, assim como estamos, com apenas uma versão, já existe um desfasamento tremendo entre as traduções do core, apps, temas e plugins, muitos deles com termos completamente inadequados e, em muitos casos, absurdos.
Há uns meses comentei num ticket do GlotPress sobre as vantagens de ter alguma forma de integração entre a versão por omissão e variantes no fluxo do GlotPress. Muitas variantes têm apenas ligeiras diferenças face à versão principal, pelo que uma faculdade de edição em paralelo, com cópia da versão principal, minoraria os erros e facilitaria muito a manutenção das traduções. Acontece que, e com alguma naturalidade (consta que não haverá muitos países com variantes suficientemente mobilizados), este ticket não teve tracção suficiente para que houvesse alguma implementação que, admito, não seja simples.
Uma outra forma de lidar com a questão seria ter em paralelo no GlotPress a versão AO90, mas apenas de leitura. I.e., o core estaria disponível também no AO90. Esta versão poderia ser implementada offline, como o PT Variants, e carregada no GlotPress a cada novo lançamento. Mas não é possível bloquear a edição, pelo que teríamos o mesmo problema de consolidação quando começasse a haver edição em paralelo.
Não tenho, de momento, uma solução para o problema. Comecei este comentário a tentar arregimentar contribuidores, mas não será fácil. Portanto, o meu objectivo centra-se, pelo menos, em tentar espoletar opiniões diversas e formas de atacarmos isto.
Não sendo justo impor-se uma norma ortográfica aos utilizadores, e em especial impor-se uma nova norma ortográfica a quem usa a antiga, também é verdade que, havendo essa possibilidade, não parece correcto que os novos utilizadores não possam usar a norma ortográfica advinda do AO90. A disponibilização do PT Variants foi uma forma de atenuar essa falha, numa altura em que o WordPress ainda não reconhecia variantes. Mas agora que reconhece, como é que vamos lidar com isto?
Álvaro Góis 23 Nov 2015, às 22:54 Permalink | Inicie a sessão para responder
Entretanto, o GlotPress está prestes a virar plugin: https://wordpress.org/plugins/glotpress/
Isso talvez facilite algumas ideias sobre como hackar a coisa…
José Freitas 24 Nov 2015, às 14:04 Permalink | Inicie a sessão para responder
Embora me prepare para engolir um sapo de um tamanho de um elefante africano, acho que a comunidade deve debater a transição da ‘versão oficial’ para o AO90.
O período de transição ou já terminou ou termina dentro de meses – em Setembro de 2016 – e não há sinais de qualquer mudança na política actual.
De resto, creio que a haver alterações estas não irão significar um regresso ao pré-AO90 mas sim a correcção de incongruências do acordo.
Por muito que me custe reconhecer, podemos estar numa acção de resistência activa mas que não passará de uma luta quixotesca.
Também não tenho uma solução para este problema.
Tenho as seguintes sugestões:
Marco Pereirinha 25 Nov 2015, às 11:08 Permalink | Inicie a sessão para responder
O desenvolvimento do @carlos-miguel-silva está em banho maria, uma vez que o trabalho de casa não foi feito por quem pediu a feature. Pelos visto foi encontrado no repositório algo do género do que estava a ser cozinhado.
Álvaro Góis 25 Nov 2015, às 12:41 Permalink | Inicie a sessão para responder
Não estou a par disto. Posso ajudar em alguma coisa?
Pedro Mendonça 24 Nov 2015, às 14:16 Permalink | Inicie a sessão para responder
Parece-me que a necessidade de adoptar o AO90 dependerá do tipo de site. Provavelmente o site de um serviço público terá muito maior necessidade de cumprir com as novas normas do que um pequeno site em que o autor continue a preferir não mudar.
Considerando o que o Álvaro disse sobre a facilidade de conversão dos textos pré-AO90, sendo que o inverso não é possível, continua a parecer-me boa ideia manter a versão original em pré-AO90, com conversão automatizada a cada versão do core.
Desde que entraram os plugins e temas para a plataforma de tradução que a confusão aumentou, por um lado é bom para a consolidação, por outro é impossível que todos os plugins mantenham traduções activas sem que aumente também a quantidade de validadores. Alguns plugins / temas tinham já uma comunidade de tradutores, faria algum sentido que as permissões de edição e validação não fossem apenas genéricas por Language Team, mas também por sub-projectos, por plugins, core, etc. Isto seria uma boa opção principalmente para a gestão do core.
Álvaro Góis 24 Nov 2015, às 14:20 Permalink | Inicie a sessão para responder
@pedro-mendonca: as permissões de validação são por subprojecto. As permissões de edição são globais, existem para todos os utilizadores registados, para qualquer projecto.
Pedro Mendonça 24 Nov 2015, às 14:24 Permalink | Inicie a sessão para responder
Não sabia, isso torna tudo menos assustador 🙂
Álvaro Góis 24 Nov 2015, às 14:36 Permalink | Inicie a sessão para responder
No caso do AO90 não. Porque se se pudesse limitar as permissões de edição na versão AO90 (core), nós poderíamos ter essa variante em paralelo, que só seria actualizada via importação da versão oficial depois das respectivas conversões. Ou seja, temas e plugins poderiam ter versões AO90 abertas, consoante os editores interessados, o core manteria a consolidação de termos e expressões entre ambas as variantes, pois não haveria editores a contribuírem apenas para uma das versões.
Mas como isso não é possível, penso que as opções passarão por: 1. tornar isso possível com o contributo dos nossos devs 😉 e/ou 2. abrir a variante mesmo assim e esperar pelo trabalho que se avizinha.
Só uma coisa é que é certa: depois de criada, não há como voltar atrás.
PS: há uma 3.ª hipótese, que é o @lightningspirit fazer a tal ferramenta que é o Lince invertido, que passa de AO90 para português 😛 Aí poderíamos estar descansados, contribuiríamos todos para uma única versão e a outra era mantida com uma conversão automática.
PS2: há uma 4.ª hipótese… desenvolver-se um addon para o GlotPress que faça a actualização automática da versão AO90 a partir do português, usando as regras actuais de conversão. No fundo aquilo é uma lista fechada, com regras (estúpidas, algumas, é certo) mais ou menos claras e estabelecidas.
Pedro Mendonça 24 Nov 2015, às 14:44 Permalink | Inicie a sessão para responder
Em todo o caso, mesmo que não se possa fechar a edição da versão que será traduzida automaticamente, na criação da variante pode ficar documentado que é uma tradução automática e que será reposta a cada nova versão. Com esta informação, os tradutores saberão que não valerá a pena investir na tradução dessa mesma variante.