[Stoq-devel] Arquivos de tradução e controle de versão

Leonardo Vilela Pinheiro leonardo.pinheiro at dobemsoftware.com
Mon May 12 09:34:50 BRT 2008


Em 11/05/2008, às 22:30, Johan Dahlin escreveu:

> Leonardo Vilela Pinheiro wrote:
> [..]
>> Depois que enviei a análise heurística de usabilidade, ficou claro  
>> que muitas mudanças que quero implementar não estão nos planos da  
>> Async. Portanto não é possível manter as árvores sincronizadas.
>
> Não estou entendendo nada do que você está falando.
> Quais mudanças você está falando sobre?

Uma vez mandei por email para stoq-devel (ou stoq-users) um documento  
chamado "Análise heurística de usabilidade do Stoq 0.9.4", com  
diversas propostas de alterações no Stoq. É destas mudanças que estou  
falando. Falando em um português mais fácil: poucas das minhas  
sugestões foram suportadas pela Async. Mesmo que eu implemente todas  
as minhas alterações na minha árvore, não é possível mandar patches  
para a Async, pois como a Async não suporta as minhas mudanças, a  
Async não vai aplicar meus patches na árvore principal do Stoq. Por  
isso, não é possível manter a  minha árvore sincronizada com a árvore  
principal do Stoq.

>> Esta solução não necessariamente acrescenta complexidade para o  
>> usuário. Ela vai facilitar muito a vida de tradutores e mesmo a  
>> vida dos programadores. A compilação do "binário" pode acontecer  
>> quando o Stoq
>
> O usuário em desse caso sou eu como desenvolvedor ou distribudor, e  
> vai complicar minha vida.

O usuário neste caso é você? E os tradutores e programadores, são  
usuários também? O mecanismo tem que facilitar a vida de quem?

Imagine desenvolvedores mantendo árvores separadas do Stoq.  
Atualmente, eles têm dificuldades causadas pelo formato de arquivo .po  
para revisar, gerar patches e mergear versões diferentes. Com um novo  
esquema de tradução, essas dificuldades desaparecem.

Imagine voluntários criando novas traduções do Stoq. Atualmente, eles  
precisam abrir um arquivo .po horroroso e confuso, editar o arquivo  
manualmente, tem que rodar um programa chamado kiwi-i18n, tem que  
testar, deve ser um processo muito difícil se o usuário não for  
experiente. Com um novo esquema de tradução, vai ser muito mais fácil  
traduzir o Stoq.

Então pergunto novamente: o mecanismo de tradução tem que facilitar a  
vida de quem?

Este mecanismo que sugeri não precisa ser criado por você (Johan). Por  
que este mecanismo vai complicar a sua vida, como desenvolvedor ou  
distribuidor? Realmetne não entendi seu argumento. Eu gostaria que  
você explicasse com mais detalhes, para que eu entenda melhor seu  
ponto de vista.

>> for executado e perceber que o "fonte" das traduções está "sujo",  
>> da mesma forma que o Python recompila os .py para .pyc.
>
> Certo, mas quem vai atualizar os scripts do release, pactoes do  
> ubuntu e fedora para fazer isso?

O próprio Stoq é quem vai verificar se os arquivos estão sujos e, se  
estiverem sujos, vai atualizá-los. Estou dizendo que o executável / 
stoq/bin/stoq (ou outro) é quem deve fazer isso (automaticamente), a  
partir de uma nova versão. Essa é a idéia.

Qual é o impacto que isso causará nos pacotes do ubuntu e fedora? Não  
estou conseguindo imaginar impacto. Vai continuar tudo igual, não é?

Quanto a "quem" vai fazer este mecanismo, posso encontrar alguém.



More information about the Stoq-devel mailing list