Olá, trocando o assunto da mensage para facilitar a discussão.
Lembrando que essa questão das pseudo-urls está descrito na wiki: https://wiki.debian.org/Brasil/Traduzir/WebWML#Vis.2BAOM-o_geral_da_coordena.2BAOcA4w-o_pela_lista_de_e-mails Em 12/01/2025 16:22, Daniel Martineschen escreveu:
oi Paulo, colegas, Deixa ver se entendi, o fluxograma de trabalho é: ITT -> RFR -> ITR -> LCFC -> DONE certo?
Existem 2 pessoas (ou mais pessoas envolvidas): 1: tradutor 2: revisor(es)O tradutor começa mandando um ITT antes de começar a tradução, avisando que vai começar a trabalhar naquele arquivo.
Depois da tradução feita, o tradutor vai mandar o arquivo pra lista, respondendo a mensagem anterior e mudando de ITT para RFR. E ele aguarda.
Um revisor vai responder a última mensagem mudando de RFR para ITR.Se a revisão for de um arquivo muito pequeno, que ele vai levar poucos minutos pra revisar, ele pode responder o RFR já com a revisão, sem precisar fazer o ITR antes. Se for um arquivo grande, ou mesmo um pequeno que vc vai levar mais tempo, sempre mande o ITR.
Se o revisor mudou de RFR para ITR anteriormente e está respondendo a mensagem com a revisão, ele deve mudar de ITR de volta pra RFR.
Então foi: ITT - RFR - ITR - RFR tradutor - tradutor - revisor- revisor O tradutor inicial vai aceitar ou discutir a revisão do revisor. O tradutor pode usar RFR2, RFR3, etc.Quando o tradutor achar que está tudo ok, e não existe mais discussão, ele vai mudar de RFR para LCFC.
Se outro revisor quiser revisar o LCFC, ele pode novamente mudar de LCFC para ITR e o processo recomeça. Isso é muito raro de acontecer.
Se está em LCFC, o tradutor vai esperar alguns dias e se nada acontecer, ele tem 2 opções:
1) Se o tradutor não tem direito de escrita no repositório do site do Debian (para arquivos wml) ou não sabe fazer o processo de abertura de BUG para arquivos .po, ele pode pedir que alguém mais esperiente faça esse processo pra ele e faça o DONE das mensagens na lista.
2) Se o tradutor tem direito de escrita no repositório do site do Debian ou sabe fazer o processo de abertura do bug, ele mesmo faz o processo de envio do arquivo e faz o DONE das mensagens.
Se o tradutor sumir por vários dias e ter um LCFC pendente, o pessoal mais experiente pode fazer o processo andar também, fazendo o DONE e enviando o arquivo.
Então foi: RFR - LCFC - DONE revisor/tradutor - tradutor - tradutor (ou alguém com mais experiência).
O que eu fiz foi mudar para ITR, o meu "erro" foi ter respondido apenas para o Charles em vez de para a lista. Quando mandei o email para a lista eu já tinha terminado a revisão, que foi apenas confirmar que não tinha nenhum problema.
Ah ok, faz sentido. Não esqueça de sempre responder pra lista :-) É chato, mas com o tempo vc vai fazer isso automático.
Mas notei que talvez tenha algum problema com o bot que controla as versões, pois na página de estatísticas [1] este documento ainda consta no status RFR, mesmo eu tendo enviado email com ITR, e depois Charles ter enviado com DONE.
As vezes o script demora pra atualizar mesmo.Não confie muito na página de estatística para processos feitos a pouco tempo.
Agora estou olhando que a última vez foi em: 13 Jan 2025 12:17:15 UTC Agora é 9:40 UTC-3 (Brasil)
Da mesma maneira, o outro do mysql (traduzido pelo adrian) que revisei também não saiu do status RFR, apesar de eu ter enviado o email com o assunto ITR e o Adriano ter mudado ele para DONE.
Mesma coisa acima.
Pelo que entendi, inclusive no vídeo explicativo do Paulo, o bot rastreia a lista de hora em hora e atualiza os status das traduções conforme os emails. Me parece que em algumas situações a máquina de estado do bot fica presa em RFR se não seguimos estritamente o fluxograma.Ou estou vendo problema onde não tem?
Eu não tenho certeza se é de hora em hora, mas eu acho que não. Vou tentar acompanhar hoje pra ver.Mas pode tá falhando mesmo, por isso eu não confio muito de olhar a página de status para processos muito recentes. Confio mais de olhar o meu thunderbird e a árvore de threads, que conversamos sobre isso no canal semana passada.
Abraços, -- Paulo Henrique de Lima Santana (phls) Belo Horizonte - Brasil Debian Developer Site: http://phls.com.br GPG ID: 0443C450
OpenPGP_signature.asc
Description: OpenPGP digital signature
