Olá Adriano, Mesmo em intervalos curtos, pode haver sobre-esforço desnecessário como ocorreu ontem com a revisão do Developer.wml. Mesmo depois de eu ter enviado o ITR para o referido arquivo, houve duplicidade na revisão e dois patchs foram enviados ao tradutor. Com certeza, isso ocorreu devido às falta da prática da utilização do ITR, principalmente por parte dos novos colaboradores.
Um abraço! On 2/13/18, Adriano Rafael Gomes <adrian...@debian.org> wrote: > On Mon, Feb 12, 2018 at 04:25:51PM -0500, Tassia Camoes Araujo wrote: >>Minha sugestão é: ao começar a trabalhar, estime o tempo que vai levar >>numa tarefa (com a prática, fica mais fácil estimar). Se vc acha que >>vai conseguir concluir "numa sentada", geralmente, não vale a pena >>mandar o ITR/ITT, pq o RFR vai chegar antes mesmo da maioria das >>pessoas verem o ITR/ITT. Se é algo que vai ficar pro outro dia, aí >>sim, vale a pena avisar a todos que vc tá trabalhando nisso. > > Tássia, isso tudo que você disse faz sentido para mim. > > Seguem os meus 2 centavos também :-) > > A ideia do ITT e do ITR é sinalizar a intenção de realizar algum > trabalho, de modo a evitar trabalho duplicado. > > A possibilidade de acontecer alguma duplicação de trabalho realmente é > menor se o intervalo de tempo entre a intenção e a concretização do > trabalho for pequeno. > > Dessa forma, a sugestão de enviar ITT e ITR quando é algo que vai ficar > pronto "no outro dia" me parece que pode funcionar. > > No entanto, vale lembrar que já tivemos alguns problemas com os > po-debconf que poderiam ter sido evitados com um ITT ou um ITR. > > Há casos onde um arquivo já foi traduzido mas, por algum motivo, ainda > consta como não traduzido na lista de pacotes a traduzir. Alguém inicia > uma segunda tradução, desnecessariamente, que acaba sendo descartada. > Ponto para o ITT. > > Um outro caso que também acontece é o de chegarem duas revisões feitas > em paralelo sobre a mesma versão de um arquivo, com patches > conflitantes. Isso dificulta o trabalho do tradutor, que tem que > integrar esses patches. Com um ITR, as revisões podem ser feitas > sequencialmente, o que elimina os possíveis conflitos entre os patches. > Ponto para o ITR. > > De qualquer modo, enviar ITT e ITR é mais seguro para evitar duplicação > de trabalho e não adiciona tanto sobre-esforço. Para intervalos curtos, > o risco de não enviá-los é menor. > >
