Olá, Da questão de inserção de ferramental, eu bem imagino. Lido com a mesma situação no manual no php.net. Isso dito, eu também fiz alguns experimentos que deram certo.
Por exemplo, houve uma época que o manual do PHP estava num git interno, quase se ferramental ou interface, depois de migrações do CVS e SVN. Mas via que projetos no GitHub facilitavam a vida de quem já era programador. Daí eu montei, por conta própria, um espelho ponte entre esse git interno e o GitHub. E isso ajudou em muito a montar ferramental, primeiro experimental que depois foi incorporado no ferramental oficial, e ajudou muito mais em atrair uma quantidade enorme de novas contribuições, da população enorme de programadores que existe justamente como usuários do GitHub. É usar as possibilidades de código livre à favor numa situação dessas. Pode dar fork, pode desenvolver. Claro que, nesses casos, tomando cuidado de não sair muito da estrutura oficial. No caso, a ponte espelho tinha ferramental automatizado que sincronizava oficial -> ponte, e os pull requests recebidos no espelho eram aplicados diretamente no oficial, de forma que o espelho nunca estava a frente do oficial. E quando falo de ferramental, falo de coisas como qualidade e dia a dia. Gerar estatísticas, gerar diffs automatizados, publicar esses diffs automatizados como "micro tarefas". Claro que ferramentas como DDTSS e po/xliff/weblate já fazem isso e muito mais. Falo isso não pensando em desenvolver por desenvolver, por exemplo, para ajudar um potencial público que se queira atrair. Não. Falo de programar para resolver alguma questão que seja muito relevante à essa tradução, algo que atrapalhe no dia a dia mesmo. Uma das coisas que eu fiz, por exemplo, são scripts que baixam uma atualização em específico, realizam todos os procedimentos de validação prescritos em manual, prepara o email, quase tudo em fim, ficando o trabalho mesmo de revisar os diffs por cima e validar que o conteúdo do email faz sentido. E esse longo email é para contextualizar isso no que comentei no Telegram, de reuniões e eventos de revisão. Embora as ferramentas façam isso até bem, o fazem nos "átomos" em vez de nos textos contextualizados. Os textos contextualizados provavelmente só existem no arquivo original já mesclado, arquivos esses que são mantidos em gitlab (até onde eu vi). Daí que, no contexto específico de revisões, o uso maior do gitlab (que é uma ferramenta em si mesma, e já é utilizada) talvez seja algo a se utilizar mais. André
