doc-pt_br
doc-pt_br copied to clipboard
php
Coordenação 2024
Para diminuir duplicidades de esforços, peço que deem um toque aqui antes de começar um dia de tradução, indicando quais arquivos ou pastas pretendem trabalhar no dia ou nos próximos dias. Não precisa ser nada muito elaborado, apenas informar direto os arquivos ou pastas pretendidas. Reservas valem por 30 dias. Passou disso, daí liberado de apagar as reservas, vencidas ou já mescladas, e assim evitar que o issue fique longo de ler.
A prioridade de processamento será reserva-temporal. Terá o PR preferido quem fizer a reserva primeiro, e terá o PR preterido quem enviar PR em cima de arquivo/diretório reservado nesse issue.
Pode-se encaminhar também PRs parciais, a serem complementados posteriormente. Nesse caso, mudar os PR para Draft, e assim indicar que eles não estão prontos para mesclagem.
Aberto para comentários, assim como pode-se utilizar esse issue para qualquer outra questão ou discussão de coordenação entre tradutores/editores.
Está aberto também a continuar mandando PRs sem fazer reserva, apenas aplicado às preferências/preterências acima. Eu bem sei que quebra rotina de reservar em vez de só sair traduzindo, mas é o jeito de manter o processo organizado. O risco de se perder trabalhos por duplicidade continua existindo pelo caminho de não reservar, o que era a situação de antes dos issues de coordenação.
Mudanças: A sinalização de PR enviado incompleto como Draft, e incremento do tempo de reserva, dada a melhora substancial dos arquivos desatualizados.
Para avisar, teve uma alteração transversal nos fontes em inglês, que mexeu em bastante arquivos, eliminando alguns arquivos fontes e trechos que geravam páginas praticamente em branco no manual compilado. Eu mandei uma alteração que corrige a compilação local na minha máquina, mas fora isso eu provavelmente só vou pegar os arquivos meu maintainer para atualizar, aos poucos.
Como aparentemente só tem três tradutores ativos, daí desconsiderar a pré-reserva de maintainer de 90 dias para fora dos três tradutores ativos, liberado a atualização sem esperar 90 dias e puxar o maintainer se quiserem, também antes dos 90 dias.
https://github.com/php/doc-pt_br/wiki/Tag-de-revis%C3%A3o
Até mesmo, como agora tem dois tradutores novos bem ativos, e revcheck praticamente zerado, gostaria de ouvir comentários a respeito de baixar a pré-reserva de 90 dias para 30 dias, e assim facilitar ainda mais manter o revcheck zerado, ou de eliminar a pré-reserva totalmente, em favor dos issue de coordenação.
Por fim, outra alteração nos originais foi uma migração/replicação da documentação do How To para markdown local. Eu estou pensando em dedicar tempo para replicar isso, após terminar de atualizar os arquivos meu maintainer. Na replicação eu penso em manter o README.md curto, para não assustar tanto quem olha pela primeira vez, e replicar em massa tanto os markdown como quase tudo o que está no wiki para um GUIA.md, longo e centralizado.
Boa tarde, poderia baixar para 30 dias, acredito que um tradutor ativo, em circunstâncias normais, não ficaria mais de 30 dias sem colaborar. Mas vejo também que hoje para nós, a questão do "Maintainer" tem pouco importado visto a quantidade de tradutores. Leonardo e eu temos nos entendido bem nesse quesito. Como zeramos as revisões, eu tenho focado bastante em traduções completas e ele tem cuidado das novas revisões.
Mas concordo que manter a coordenação, aviso de WIP (work in progress) e o respeito aos prazos as reservas desses trabalhos, segue sendo muito importante.
Referente ao guia, concordo 100%. Quanto mais simples, mais atrativo será aos novos colaboradores. Confesso que adiei bastante o início da minha colaboração nas traduções visto a toda a documentação introdutória para isso.
Para avisar, teve uma alteração transversal nos fontes em inglês, que mexeu em bastante arquivos, eliminando alguns arquivos fontes e trechos que geravam páginas praticamente em branco no manual compilado. Eu mandei uma alteração que corrige a compilação local na minha máquina, mas fora isso eu provavelmente só vou pegar os arquivos meu maintainer para atualizar, aos poucos.
Como aparentemente só tem três tradutores ativos, daí desconsiderar a pré-reserva de maintainer de 90 dias para fora dos três tradutores ativos, liberado a atualização sem esperar 90 dias e puxar o maintainer se quiserem, também antes dos 90 dias.
https://github.com/php/doc-pt_br/wiki/Tag-de-revis%C3%A3o
Até mesmo, como agora tem dois tradutores novos bem ativos, e revcheck praticamente zerado, gostaria de ouvir comentários a respeito de baixar a pré-reserva de 90 dias para 30 dias, e assim facilitar ainda mais manter o revcheck zerado, ou de eliminar a pré-reserva totalmente, em favor dos issue de coordenação.
Por fim, outra alteração nos originais foi uma migração/replicação da documentação do How To para markdown local. Eu estou pensando em dedicar tempo para replicar isso, após terminar de atualizar os arquivos meu maintainer. Na replicação eu penso em manter o README.md curto, para não assustar tanto quem olha pela primeira vez, e replicar em massa tanto os markdown como quase tudo o que está no wiki para um GUIA.md, longo e centralizado.
Acredito que para atualização (derivadas da revisão em inglês), não seria necessário esperar. Eu mesmo algumas vezes atualizo arquivos de outros mantenedores no mesmo dia em que aparecem na lista. É bom para os usuários do manual, que terão a página em português atualizada mais rapidamente. Já para mudar o nome do mantenedor, concordo em mudar de 90 para 30 dias.
revcheck novamente zerado, oh, felicidade. Da discussão acima, pelo jeito há consenso de se eliminar a pré-reserva totalmente. Daí virando de quem pegar o arquivo primeiro, podendo ocorrer algum conflito de edição e/ou esforço duplicado. E apesar desses termos, eu não vejo problema. Quando o manual desce para poucos tradutores, meio que é esse o sistema mesmo. Não havendo nova discussão, daí eu já viro a documentação do wiki nessa direção, durante a conversão de wiki para markdown. E também apago essa mensagem e as duas mensagens textuais acima, para facilitar navegar nesse longo issue.
Eu particularmente vou focar na conversão de wiki para markdown, e mais em resolver os trocentos avisos que acumulou para mim nas ferramentas de QA. Agora que eu consegui emplacar como ferramenta oficial, também vou virar o ferramental local para rodar o QA no processo normal. Além disso, teve algumas dezenas de arquivos que foram alterados no Inglês mas que por um bug no recheck, foram ignoradas. São todas coisas que não aferam o revcheck, e daí nem devo mexer em arquivos meu maintainer tão cedo.