[Kde-i18n-pt_br] [LDP-Br] Controle de qualidade dos nossos trabalhos

Frederico Goncalves Guimaraes fgguimaraes em teia.bio.br
Quarta Março 11 12:20:49 CET 2009


Olá colegas das listas,

Consta no registro %LW10292 do Livro da Grande Teia que,
em 10/03/09, Leslie escreveu o seguinte:

> Por que? Algumas razões:
>  + é mais fácil procurar em um único lugar que em vários (pesquisa
> rápida) pelo mesmo erro em vários lugares
>  + uma vez que corrige-se o bug na tradução, fica fácil saber em que
> versão da tradução foi traduzida e enviada para o upstream
>  + independência de o projeto origem ter ou não um
> bugzilla/gerenciador de bugs
>  + outros já utilizam esse sistema (vide DEBIAN)
>  + criam-se referências importantes para futuras traduções
>  + acompanhamento "local"

Os argumentos que o Leslie apresenta são os que eu defendo para a
proposta que eu apresentei. Especialmente o fato de centralizarmos toda
a informação em um lugar só. Ficaria mais fácil darmos alguma resposta
do tipo "tal erro já foi corrigido na versão tal" ou "esse erro ainda
nos é desconhecido". Além disso, como o Leslie também apresentou,
alguns pacotes não estão associados a nenhum "grande projeto". Por
exemplo, o Claws Mail que é um softwares que eu traduzo, não está
vinculados a nenhum projeto maior de tradução. Igual a ele eu sei que
existem vários outros.

> Contras:
>  + trabalho de registrar o bug em 2 lugares

Sei que esse motivo contrário é forte e concordo que ele não é
interessante. Até mesmo porque corre-se o risco de as informações
perderem sincronismo, quando são tratadas em mais de um lugar.

E uma vez que pelas respostas até agora eu percebo uma tendência a
manter o modelo atual, que tal se unificássemos pelo menos as
informações? Adaptando um pouco a idéia do Vladimir, poderíamos criar
uma página de "controle de qualidade de traduções" que serviria para
colocarmos informações sobre o estágio atual das traduções e que
indicasse quais os procedimentos a serem adotados para o envio de
erros. Já os pacotes não vinculados a um projeto maior poderiam
utilizar a estrutura do Trac para seu controle de erros. Nesse caso
preservaríamos a situação atual de controle de erros (ou seja, cada
projeto com seu fluxo de trabalho), mas teríamos um único local
indicando qual procedimento o usuário deveria adotar. Essa página seria
citada em todos os projetos e divulgada amplamente nos meios de
comunicação aos quais temos acesso.

Vejam bem, estou pensando no usuário final, sem conhecimento técnico,
que está usando o programa e encontra o erro. Pra nós pode parecer
trivial entrar no bugzilla, mas não é assim para todos. Um bom exemplo
desse usuário são os milhares de professores cujas escolas estão
recebendo laboratórios de informática.

E então, o que vocês acham?

Um abraço e até mais.


Frederico
-- 
Linux User #228171
Debian-BR User #434
Sítio pessoal: http://teia.bio.br
Projeto Software Livre Educacional: http://sleducacional.org

"Liberdade, essa palavra que o sonho humano alimenta, que não há
ninguém que explique e ninguém que não entenda." (Cecília Meireles)


Mais detalhes sobre a lista de discussão Kde-i18n-pt_br