[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