Este PR é pra resolver#135, certo?

isso

Ao invés de executarpocount para cada arquivo PO e ir adicionando as strings, que tal executarpocount em todos de uma só vez e pegar apenas o total?

$ pocount*.po**/*.poProcessing file: about.poType               Strings      Words (source)    Words (translation)Translated:      10 (100%)        166 (100%)             170Fuzzy:            0 (  0%)          0 (  0%)             n/aUntranslated:     0 (  0%)          0 (  0%)             n/aTotal:           10               166                    170Unreviewed:      10 (100%)        166 (100%)             170# ....# pulei para o finalProcessing file: whatsnew/index.poType               Strings      Words (source)    Words (translation)Translated:       3 (100%)         69 (100%)              78Fuzzy:            0 (  0%)          0 (  0%)             n/aUntranslated:     0 (  0%)          0 (  0%)             n/aTotal:            3                69                     78Unreviewed:       3 (100%)         69 (100%)              78Processing file: TOTAL:Type               Strings      Words (source)    Words (translation)Translated:   27887 ( 50%)     476230 ( 42%)          503086Fuzzy:            0 (  0%)          0 (  0%)             n/aUntranslated: 27775 ( 49%)     653717 ( 57%)             n/aTotal:        55662           1129947                 503086File count:     483

Pode-se corresponder ao texto "TOTAL:" como marcador de inicío para considerar a leitura de conteúdo e aí buscar correspondência do padrãopattern_translated_strings. Seria, assim, uma execução dopocount por commit.

Nota:git ls-files é uma alternativa para assegurar que apenas arquivos .po rastreados pelo repositório git sejam inclusivos. Mas talvez não seja necessário.

Nessa ideia, como poderia ser pego o pocount total de um commit antigo? não consegui achar nada a respeito.

Nessa ideia, como poderia ser pego o pocount total de um commit antigo? não consegui achar nada a respeito.

git switch com --detach. Por exemplo:git switch d16bd17181b2cc50d822eecbca9b13c51903dc7e --detach. Para voltar:git switch 3.12.

Para obter o branch atual, usegit branch --show-current (me parece melhor que forçar via código um branch).

Outra opção é usar a bibliotecaGitPython.

refatorei sobre aqueles aspectos do git switch, acredito que ainda falte o "se negativo, retorna 0"

refatorei sobre aqueles aspectos do git switch, acredito que ainda falte o "se negativo, retorna 0"

Isso fazmesmo sentido,@rffontenelle ? Pra mim, não faz. Qual é a informação que você tem que eu não tenho? :)

@guilhermesrc

E eu acho que tá dando uma exagerada no uso detry...except. Quais são as exceções possíveis?
CapturarException não é uma boa prática.

E depois retornar0 pode dar algum tipo de confusão com "se negativo" ou "nada mudou mesmo".

refatorei sobre aqueles aspectos do git switch, acredito que ainda falte o "se negativo, retorna 0"

Isso fazmesmo sentido,@rffontenelle ? Pra mim, não faz. Qual é a informação que você tem que eu não tenho? :)

Vamos para um exemplo.

Quinta-feira temos 20000 traduzidas. Sexta-feira as strings fontes foram atualizadas e alterações resultaram agora em termos 19900 porque pequenas alterações em strings existentes, "apagando" a tradução.

Neste caso, subtrair 19900 de 20000 (atual menos o anterior) vai dar 100 negativo. Aqui a diferença não é zero somente porque "perdemos tradução" (ainda aparecem como sugestões do Transifex). Neste caso, acho que podemos considerar zero tradução.

refatorei sobre aqueles aspectos do git switch, acredito que ainda falte o "se negativo, retorna 0"

Isso fazmesmo sentido,@rffontenelle ? Pra mim, não faz. Qual é a informação que você tem que eu não tenho? :)

Vamos para um exemplo.

Quinta-feira temos 20000 traduzidas. Sexta-feira as strings fontes foram atualizadas e alterações resultaram agora em termos 19900 porque pequenas alterações em strings existentes, "apagando" a tradução.

Neste caso, subtrair 19900 de 20000 (atual menos o anterior) vai dar 100 negativo. Aqui a diferença não é zero somente porque "perdemos tradução" (ainda aparecem como sugestões do Transifex). Neste caso, acho que podemos considerar zero tradução.

Então... isso não deveria ser -100?

Porque agora temos a certeza que há 100 novas strings pra traduzir, seja porque são realmente novas, seja porque algo que estava traduzido deixou de estar (o motivo me parece irrelevante). E aí sabemos que há trabalho de tradução pra ser feito. Se eu vejo 0, vou ignorar.

Isto é, tou pensando no caso de uso disso ser útil pra saber o que precisa ser traduzido. De repente, você tá pensando em outro caso de uso.

Vendo o título do PR e também a descricao em#135 parece que é isso mesmo... você focou no caso pontual de saber quanto traduzimos em uma sprint (e aí não faz sentido dizer "destraduzimos X strings") e eu pensei em comparar dois commits quaisquer...

Se possível, eu agora quero os dois. :D

Deixaria essas funções já feitas como estão, para esse cenários mais amplo que eu pensei, e escreveria nova(s) para esse caso do "se negativo, retorna 0"

@guilhermesrc

E eu acho que tá dando uma exagerada no uso detry...except. Quais são as exceções possíveis? CapturarException não é uma boa prática.

E depois retornar0 pode dar algum tipo de confusão com "se negativo" ou "nada mudou mesmo".

Nossa realmente ficou bem genérico revisando, mais tarde reescrevo. Agora pensando, talvez no regex e ao manipular o OS ali seriam as exceções mais validas.

Tirei quase todos os exceptions, exceto a de manipulação do sistema, somente alterei a biblioteca.