openerp-brazil-team team mailing list archive

[Cloves Almeida <cjalmeida@xxxxxxxxx>]

Minhas considerações sobre suas considerações :)
> Vamos falar sobre os 3 problemas:
>
>   
> > 1) é complicado ter feedback sobre que vc esta traduzindo, vc tem que mandar
> > no Launchpad, alterar de vez, baixar, testar, se tiver errado tem que
> > corregir la senao vc ja atrapahla todo mundo.
> >     
>
> De fato a sincronia é um problema. Uma solução é eleger um gerente de
> projeto para organizar as equipes e mesclar os trabalhos.
>   
O Rosetta é online e nele as modificações são imediatas. O problema é 
que a modificação não aparece imediatamente no OpenERP, então podem 
haver erros por conta da falta de contexto. Mas isso não é tão grave.
> > 2) para funcionar direito, os committer da Tiny tem que exportar os termos
> > mais atuais para ser traduzidos no Rosetta, se nao for vaoi faltar coisas na
> > hora de importar as traduçoes no OpenERP de volta. Acho que agora que a 5.0
> > esta mais estabilizada, isso é menos problema.
> >     
>
> Ok, o gestor seria responsável por manter-se conectado com a Tiny.
> Provavelmente a Tiny deve ter um conselho que reúne este tipo de
> pessoa, então inserimos um falador tupiniquim neste meio para
> mantermos a harmonia entre as traduções.
>   
Como disse o Raphael, a versão 5.0 está bem estável. O pessoa da Tiny 
está tão atarefado que quanto menos dependermos deles, melhor.
>   
> > 3) Mesmo assim, ainda precisa Tiny fazer uma operaçao para importar as
> > traduçoes do Launchpad de volta nas branches do OpenERP para todo mundo se
> > beneficiar
> >     
>
> Bem, neste caso realmente estaremos frágeis, pois necessitaremos de
> uma presença mais ativa por parte da Tiny em resposta ao nosso
> trabalho. Alternativamente podemos simplesmente disponibilizar os
> módulos traduzidos e estes serem adicionados à pasta addon, não?
>   
Reitero que a solução é trabalhar com as branches estáveis no caso da 
tradução dos módulos oficiais. Nos módulos contribuídos, se o Rosetta 
não atender, podemos traduzir no módulo mesmo e pedir a Tiny para 
incluir no Rosetta. Os arquivos .po são muito simples e tem vários 
programas que auxiliam na edição.
> Eu não sei qual é a sua proposta para facilitar a tradução e migração
> entre versões, mas se está sugerindo algo, deve ser para melhor.
> Conseguiu algum retorno da Tiny?
>   
Pelo que vejo nos fóruns, a migração do 4.2 para o 5.0 foi meio 
traumática. Parece que com a 5.2 a Tiny está sendo bem mais cuidadosa.
> Com relação aos documentos, vamos seguir para os fontes, com toda
> certeza deve ter origem no documento oficial e atualizado, e ainda
> assim manter a sincronia. No cenário atual não vejo outra maneira
> senão pelo Rosetta mesmo.
>
> É claro que com a tropicalização um documento anexo deverá ser construído.
>
> De qualquer maneira vamos analisar se é viável traduzir estes
> documentos ou não, mas, de qualquer forma, algum documento tupiniquim
> precisa existir, seja para treinamentos e/ou consultas posteriores.
> Para nós o inglês não é uma barreira, mas para os usuários, mesmo o
> key-user, isto é sim um problema e o simples fato de não ter tal
> material já pode inviabilizar o projeto em uma corporação no Brasil.
> Ciontudo, podemos ainda avaliar várias possibilidades como por exemplo
> a confecção de nova documentação construída originalmente em
> português.
>   
IMHO, as prioridades da tradução/documentação devem ser

a) interface (base, addons, addons-extra);
b) OpenERP Book
c) uma extensão do OpenERP Book com as funcionalidades nativas

Acho interessante não fugirmos do OpenERP Book. Ele é bem feito e nem os 
franceses com uma comunidade muito maior que a nossa ainda conseguiram isso.

> 9. Módulos específicos do Brasil
>
> Bom, nosso objetivo é absorver o OpenERP e iniciar a criação de
> módulos específicos para o nosso ambiente corporativo, incluindo aí o
> SPED, faturamento, recebimento e a parte fiscal. Nossa empresa é
> especializada neste assunto e queremos oferecer um serviço de
> qualidade através dos módulos que construirmos e também naqueles que
> pudermos contribuir, como este q vc cita sobre emissao de NF.
>
> Por exemplo, nós temos uma solução para SPED e emissão/recepção de
> NF-e (com todas as peculiariedades relacionadas aos malditos
> webservices da SEFAZ), a idéia, até para viabilizarmos o patrocínio de
> construção e manutenção de módulos para o OpenERP, é construir
> conexões com nossas soluções, e isto inclui criar módulo para criação
> de arquivos TXT ou XML de NF-e.
>   
Excelente idéia. Se fizer um preço bom, até viro cliente ;)