GeezerVison

Este PR é pra resolver #135, certo?

isso

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

$ pocount *.po **/*.po
Processing file : about.po
Type               Strings      Words (source)    Words (translation)
Translated:      10 (100%)        166 (100%)             170
Fuzzy:            0 (  0%)          0 (  0%)             n/a
Untranslated:     0 (  0%)          0 (  0%)             n/a
Total:           10               166                    170

Unreviewed:      10 (100%)        166 (100%)             170

# ....
# pulei para o final

Processing file : whatsnew/index.po
Type               Strings      Words (source)    Words (translation)
Translated:       3 (100%)         69 (100%)              78
Fuzzy:            0 (  0%)          0 (  0%)             n/a
Untranslated:     0 (  0%)          0 (  0%)             n/a
Total:            3                69                     78

Unreviewed:       3 (100%)         69 (100%)              78

Processing file : TOTAL:
Type               Strings      Words (source)    Words (translation)
Translated:   27887 ( 50%)     476230 ( 42%)          503086
Fuzzy:            0 (  0%)          0 (  0%)             n/a
Untranslated: 27775 ( 49%)     653717 ( 57%)             n/a
Total:        55662           1129947                 503086

File 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ão pattern_translated_strings. Seria, assim, uma execução do pocount 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, use git branch --show-current (me parece melhor que forçar via código um branch).

Outra opção é usar a biblioteca GitPython.

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 faz mesmo 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 de try...except. Quais são as exceções possíveis?
Capturar Exception não é uma boa prática.

E depois retornar 0 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 faz mesmo 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 faz mesmo 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 de try...except. Quais são as exceções possíveis? Capturar Exception não é uma boa prática.

E depois retornar 0 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.