openerp-brazil-team team mailing list archive

[Henrique Meira <henrique@xxxxxxxxx>]

Raphael, agradeço a vasta explicação que enviou. Vou tentar segmentar
minhas considerações.

1. Sobre a complexidade da tradução:

Particularmente não conheço Rosetta, não sei ainda como funciona. Mas
como experiência posso relatar sobre o Netbeans. Nós tinhamos apenas
os arquivos .properties e utilizavamos um programa que reconhecia este
tipo de arquivo apresentando a versão em ingles em uma linha e uma
caixa para tradução na outra linha. Conforme ia se traduzindo o
programa mantinha as palavras mais utilizadas para que assim o
tradutor possa manter coerência em suas traduções.

Foi um trabalho árduo, então se for algo parecido, acredito que é
apenas uma questão de treinamento.


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.


> 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.

> 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?


2. Trabalho na Tiny

Este trabalho que você irá realizar na Tiny semanalmente é
especificamente mão-de-obra ou consultoria ? Pergunto isto pq podemos
conseguir nos envolver em algo também. Nós temos pessoas que podem
trabalhar em desenvolvimento e tbm temos pessoas com know-how de
negócio.

Em tempo, você já trabalhou na Tiny? Quero dizer, vc tbm foi um
desenvolvedor do OpenERP?


3. Versão 5.2 para dezembro

Esta versão irá implementar muitas coisas da listinha
https://blueprints.launchpad.net/~rvalyi ? Este é um ponto
interessante com relação a tradução. Acho que dificilmente será
possível sincronizar releases novas com traduções, e isto me leva a
pensar novamente em entregar pacotes de tradução separada da versão,
assim o "integrador" pode atualizar o programa a medida que as
traduções vão sendo liberadas.

Você diz que a tropicalização é menos importante para você neste
momento. Você ainda não tem clientes no Brasil que utilizam o OpenERP?
De repente vc tem alguns prospects e isto acaba tornando-se algo
importante. Não seria o momento de injetar gás nestes projetos de
tropicalização?


4. Inglês ruim

Um ponto preocupante, mas contornável. Acredito que uma equipe em
sinergia ajude a transformar o inglês ruim em uma boa tradução para o
português, e de lambuja ajuda a melhorar os termos em inglês,
relatando estes ao projeto oficial.


5. Curto, médio e longo prazo

Se o objetivo é tornar o projeto viável e sustentável para uma
companhia de maneira profissional, então teremos sim que nos
sacrificar no início para ultrapassar as barreiras iniciais, tais como
o inglês ruim e o treinamento com Rosetta.

Apesar de ser "gringo" você se expressa de maneira perfeitamente
compreensível e logo vemos sua experiência com o projeto. Sem dúvida o
seu envolvimento nesta engajada é fundamental. Uma pena não poder
contar com Renato Lima neste momento.


6. As propostas à Tiny

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?


7. Akretion.com

Você fala sobre integradores OpenERP, o termo integrador é o mesmo que
implantador? Ou seja, vc implanta o sistema? É que minha empresa
trabalha com integração, mas este termo é utilizado para indicar a
ligação entre sistemas. Exemplo: Integrar OpenERP com Oracle AP.


8. Patrocinar o projeto de tradução

Nós temos uma pessoa que pode trabalhar full time na tradução do
programa, logicamente é um profissional de linguística e nada entende
de ERP, contudo estará envolvido com pessoas do ramo, inclusive nesta
lista, logo terá todo o suporte técnico necessário para termos uma
tradução de qualidade.

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.

Também sou a favor de material em blogs, wikis e afins, mas
particularmente não encontrei em lugar algum... nem mesmo um simples
tutorial sobre como se fazer uma venda ou compra de mercadoria e
serviços, ou como trabalhar com impostos e registros contábeis. O
único material que encontrei a respeito deste assunto foi nesta
documentação de 1500 páginas.


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.


Bem, então é isso. Agradeço novamente suas considerações, espero poder
contribuir e assim ajudar a alavancar o OpenERP no Brasil.

Abraços a todos,

henrique.


2009/11/10 Raphaël Valyi <rvalyi@xxxxxxxxx>:
> Ola Henrique,
> Bom, primeiro vi seu log no IRC hoje. Voce nao se encontrou com o Cloves que
> esta trabalanho com OpenERP em Goias (cjalmeida no #openobject) por pouco, e
> geralmente fico la tanbem (rvalyi), menos hoje mas ou menos.
>
> Bom, vc acertou, a traduçao esta meia paradinha, seria bom ela avançar
> melhor.
> O negocio é que nao esta simples, o unico jeito que e editora Tiny consegue
> integrar é se o pessoal usa a ferramento Rosetta do Launchpad, assim que nos
> explicamos nesse tutorial:
> http://www.openerpbrasil.org/localizacao-brasileira/traducao-em-geral
> Mas ainda tem 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.
> 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.
> 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
> Tiny esta completamente sobre-carregada porque esta tendo suncesso
> international muito grande, entao nem isso os caras estao conseguindo fazer
> direito.
> Para resolver esse cresciemento, Tiny acabou de deixar publico que estava
> procurando fundos:
> http://www.bloomberg.com/apps/news?pid=20601204&sid=a0Wy0DITQBiA
> Nao tem perigro, por conhecer bem o Fabien Pinckaers, posso segurar que o
> cara so vai vender poucas shares e tudo ficara no open com mesmo espirito,
> diferentementes de algums outros (Compiere, Openbravo que venderam a alma
> tb).
> Isso permittira conseguir mais pessoas na Tiny e cuidar melhor da
> comunidade. Ate um cara so cuidando da comunidade gigante é preciso, nem
> isso eles tem. Realmente, acho que poucas pessoas fazem ideas dos milagros
> que fizearm ate agora com tantas poucas pessoas competentes que eles tem.
>
> Ainda que bem carregado, recentemente aceitei de dar uma força para Tiny
> tipo um dia por semana antes que eles conseguem um cara full time para isso.
> Ainda nao ta assinado, mas se consiguo me livrar um pouco das nossas
> integraçoes OpenERP, eu faço logo, nao farei mais do que 1 dia/semana porque
> nao posso deixar de cuidar da minha empresa Akretion.com que precisa crescer
> é alcançar massa critica.
> Mas na verdade, minha preocupaçao esta muito mais com a versao 5.2 que tera
> freeze em final de Decembro do que a tropicalizaçao porque o OpenERP so sera
> democratico e com mercado grande apenas se melhora muita coisa, apesar de ja
> estar liderando os ERP's livres.
> Quero ter certeza que nos implementamos apenas a parte importante dessa
> listinha: https://blueprints.launchpad.net/~rvalyi
> e das outras listinhas que outros tem.
> So para lembrar, ainda por falta de recursos humanos imediatos, Tiny esta
> parada em cilcos de release de um ano. Quer dizer se perdemos esse trem,
> perderemos muito tempo, fora a pequena elite que ja consegue usar do jeito
> que esta. Tropilcalizaçao podera chegar depois equanto melhorias na
> arquitectura. Para mim pelo menos é menos importante.
> Mas mesmo assim, se eu do essa força para Tiny, meu objetivo vai ser de
> conseguir melhor integrar as contribuçoes, inclusive de localizaçao.
>
> Bom, outro problema que nos temos é que nao basta so traduzir. Por iser,
> pode nao gostar, mas os caras da Tiny, inclusive do Fabien Pinckaers ficaram
> um tempinho com ingles bem ruim. A consequencia disso, é que tem chave de
> traduçao que vai precisar trocar porque:
> 1) é vergonha na cara, principlamente tira uma parte da comunidade que vao
> perfirir escutar o ingles perfeito da Compiere o Openbravo
> 2) os caras que usam no paises que falam ingles, nao tem camada de traduçao
> entao levam os erros na cara direito.
> 3) em algums paises, os tradutores estao com as maiores dificultades tanbem
> para traduzir porque nao entendem algums termes em ingles errado
> So para falar, nao ficou melhor com os outros, pelo menos pouco tempo atras,
> toda camada javascript era em espanol, e ate mais do que javascript so...
> Acho que o assunto fico bem resumido aqui:
>  http://openobject.com/forum/topic13662.html
>
> Bom, tem o curto e longo prazo. Podem ajudar nos dois sentidos:
> A curto parzo, tem que arguentar o Rosetta e os erros de ingles e tem que
> puxar o saco da Tiny para que eles integram novas traduçoes.
> No prazo medio/longo, vamos ter que atualizar essas traduçoes quando o
> ingles sera corrigido, parte porderia ser automatica talvez.
> Eu, pessoalmente, nao escrevo portugues direito, porque como vc repara sou
> gringo (frances), entao tenho muito mais valor agredado em agilizar esses
> fluxos com porcessos é soluçoes tecnicas do que contribuir tradiçoes
> aproximativas. Para completar o quadro o brasileiro experimentado do nosso
> team Akretion, Renato Lima, tambem esta super carregado com trabalho que
> ainda nao largou e projetos gringos...
>
>
> Eu tenho logo duos propostas para fazer para Tiny (vou ligar para eles
> amanha, qui hoje mas fiquei enrolado com conexao Magento - OpenERP):
> 1) vou propor de organizar um jeito de fazer alteraçoes importantes do
> codigo/traduçoes para versao 5.2 mas de um jeito que vai dar para migrar.
> Porque quando teve varias mudanças entre verçoes 4.2 e 5.0, migraçao ficou
> coisa quasi impossivel. Ja que a versao 5.0 é melhor a tentaçao poderia ser
> do imobilismo. Acho que OpenERP precisa sim ir para frente, incuindo as
> inumerosas controbuçoes a redor do mundo (depois de filtrar claro), mas
> deixar o cominho de migraçao explicito.
> Se Tiny gostar do meu plano, logo voltarei a explicar esse. Isso permittira
> de resolver isso http://openobject.com/forum/topic13662.html  como
> inumerosas coisas para mudar.
> 2) Confesso que nao conheço o assunto super bem, mas acho que o melhor seria
> um modulo para integrar traduçoes feitas localmente no OpenERP direito no
> Launchpad, usando webservices da Launchpad. So que mesmo que planejado ainda
> nao vi essa API para Rosetta. Talvez pode ser contorneado, usando HTTP e/ou
> bzr se conseguimos fazer bzr e Rosetta funcionar melhor junto.
> De qualquer jeito, vou ver isso com Tiny amanha, depois falo quais sao as
> pistas.
>
> Sobre traduçao de coisas tipo;
>
>>
>> 1o. Conhecer as pessoas envolvidas e como anda o projeto de tradução.
>
> Bom, acho que as vc vai ver a pessoas mais ativas nessa lista, mesmo que
> ainda pouca ativa.
>
>>
>> 2o. De acordo com o cenário apresentado me oferecer para ajudar e
>> também, juntamente com minha empresa, patrocinar (financeiramente) a
>> conclusão do projeto.
>
> Olha, nos Akretion.com somos integradores experimentados com OpenERP, os
> primeiros parceiros da oficial no Brasil.
> Se vc pagar por isso, podemos dar prioridade a isso sobre nossos outros
> projetos gringos (ou temos pelos menos uma pessoa que nao tem muito
> conhecimento technico mas poderia trabalhar nisso junto com nos), vc que
> sabe.
> Daqui nao muito tempo tembam faremos formaçoes, no Rio primeiro, talvez Sao
> Paulo depois.
>>
>> A ideia é ser bastante expansível, incluindo não apenas textos, rótulos
>> e mensagens do programa, mas também os principais documentos como o
>> openerp_book.pdf.
>
> Bom, sobre isso: o maior erro que pode ser feito é de traduzir esses
> documentos sem usar a mesma ferramenta do que Tiny. Por iser, o passado
> mostra que ja évoluiu muito OpenERP e a documentaçao dele, e ainda precisa
> que muda.
> Caso vc nao usar Sphinx e Launchpad para traduzir, vc nao vai saber o que
> vai ter que alterar no tempo. Vai te levar um ano para traduzir e quando for
> feito, essa traduçao ja vai estar passando informaçoes erradas, que vao
> atrapalhar as pessoas e a imagem do produto ao inves de ajuda-los.
> Isso foi que aconteceu com o wiki frances, Tiny quis ate tira-lo do ar por
> isso.
> Na minha opiniao temos que aceitar que em primeiro lugar, as pessoa vao ter
> que falar ingles para integrar o OpenERP (talvez nao para apenas usar depois
> de fomaçao, se a tropicalizaçao for boa), senao terao que ir brincar com
> Stoq ou Totvs. Como ja falei, isso ainda é verdade la na França mesmo com
> mais de 20 integradores oficiais e comunidade eu diria 20 vezes maior desde
> algmus anos. Isso ate a comunide estar grande suficente para encarar a
> traduçao completa e atualizada; accredito que so poderemos fazer isso dentro
> de um ou dois anos infelizmente. Olha so, nao a tropicalizaçao avança
> direito, ja quer mainter a traduçao de 1500 paginas de documentaçao super
> tecnica?
> E bom lembrar que é open source. Open source tem pouco dinheiro, e so
> consegue se sustentar se for international, mas em final, vence.
> Enquanto isso, sou pessoalmente a favor de artigos de blog com assunto
> definido e dominado (ja que o perimetro integral das 1500 paginas nao vai
> ser, talvez com vc pode encontrar aqui na espanha:
>  http://www.openerpsite.com/ ) para divulgar o OpenERP no Brasil enquanto
> isso. Isso é a idea por tras do portal openerpbrasil.org (que tem vantagem
> se ser independente) que mentionara esses artigos e dara visibilidade a
> eles. Tenho que dizer que bem poucos tais artigos ainda foram contribuidos
> infelizmente.
>
>>
>> p.s.: Alguém pode me dizer onde devo procurar pessoas interessadas em
>> módulos específicos para o Brasil? Como por exemplo NF-e, SPED Fiscal e
>> Contábil, Frente de Caixa, etc...
>
> Akretion, pelo menos esta trabalhando nisso:
> https://blueprints.launchpad.net/openerp.pt-br-localiz/+specs?show=all
> So que tanbem, vamos no nosso ritmo. Para nois, isso nao traz nehnum lucro
> enquanto o telefone nao para de tocar com projetos la na Europa. Nos
> balançamos o esforço entre os dois e ja somos quem mais fazem por aqui ate
> que se prova o contrario. Pessoalmente acho triste que tem que ser gringo
> que vem liderar a localizaçao brasileira...
> Nos tambem estamos envolvidos em monte de outros modulos para comunidade,
> algums atuais:
> http://github.com/rvalyi/ooor
> https://launchpad.net/magentoerpconnect
>
> Assim que falei, nos acabamos de entregar uma versao melhorada do modulo
> report_intrastat que em principio vai permittir de implementar:
> https://blueprints.launchpad.net/openerp.pt-br-localiz/+spec/extencao-fatura-em-nf
> O que sera mais um paso na direçao de Nota Fiscal electronica.
> So para lembrar, apesar de nao ainda nao divulgado (por falta de tempo), o
> plano de contas brasileira oficial ja esta na branch do modulo l10_n_br.
> Logo que nos temos a estrutura de dados para lidar completamente com Nota
> Fiscal, podemos pensar no exporte par NFE, veja so o grafe das dependenças:
> https://blueprints.launchpad.net/openerp.pt-br-localiz/+spec/exporte-nfe
> So para avisar, nos na Akretion esperaremos cliente brasileiro financiar o
> exporte XML para NFE, agora se alguem que contribuir antes, seja bem vindo.
> Nos analisemos a situaçao, nao da para ter os webservices para o OpenERP se
> comunicar com a Receita Federal diraitamente, o especificaçao é uma droga
> que parace que so foi feito para presevar o monopole de quem implementou. Na
> argentina e no Equador é muito mais simples, so no Brasil a especificaçao é
> tao laboriosa... O que vai ter que fazer, e criar exporte XML para o
> software Java da NFE que ele comunicara com a receita Federal.
>
> Bom, é isso ai. Logo que tenho o feedback da Tiny para traduçoes, eu volto a
> falar. Enquanto isso, tem muitas coisas que vc pode ajudar ou nos contar
> para suporte (so que com antecedencia porque nos estamos cheio de trabalho).
>
> Abraço
>
> Raphaël Valyi
> http://www.akretion.com.br  - primeiro integrador OpenERP parceiro da Tiny
> no Brasil
>