Merge lp://qastaging/~renatonlima/openerp.pt-br-localiz/l10n_br_base_i18n into lp://qastaging/openerp.pt-br-localiz/6.1

O jeito mais simples de solucionar os problemas de unicode é usar strings unicode (ex: u'É uma string com acentos').

> O jeito mais simples de solucionar os problemas de unicode é usar strings
> unicode (ex: u'É uma string com acentos').

IMO, o problema não são as strings ASCII mas o fato de as etiquetas estarem em português. O "correto" é que esteja tudo em inglês e a tradução no i18n, mesmo na localização.

A localização espanhola usa essa prática:

http://bazaar.launchpad.net/~openerp-spain-team/openerp-spain/6.1/view/head:/l10n_es_partner/partner_es.py

Eu não vejo vantagem em ter strings em inglês, só aumenta o trabalho
de manutenção, e elas estarem em português não inviabiliza que tenham
traduções para outras linguas. A gente deveria procurar fazer a
localização o mais bem feita e simples possivel, pois temos pouca mão
de obra.

Em 17 de julho de 2012 15:59, Cloves Almeida <email address hidden> escreveu:
> Review: Approve
>
>> O jeito mais simples de solucionar os problemas de unicode é usar strings
>> unicode (ex: u'É uma string com acentos').
>
> IMO, o problema não são as strings ASCII mas o fato de as etiquetas estarem em português. O "correto" é que esteja tudo em inglês e a tradução no i18n, mesmo na localização.
>
> A localização espanhola usa essa prática:
>
> http://bazaar.launchpad.net/~openerp-spain-team/openerp-spain/6.1/view/head:/l10n_es_partner/partner_es.py
> --
> https://code.launchpad.net/~renatonlima/openerp.pt-br-localiz/l10n_br_base_i18n/+merge/114481
> You are reviewing the proposed merge of lp:~renatonlima/openerp.pt-br-localiz/l10n_br_base_i18n into lp:openerp.pt-br-localiz.

A localização BR é para ser usada mesmo só no Brasil, pelo que apesar de defender a abordagem de desenvolver tudo em Inglês e traduzir, sou inclinado a concordar com o Leonardo.

No entanto módulos ou código que possam ou venham a ser usados noutras localizações deverão ser feitos com expressões inglesas.

> > O jeito mais simples de solucionar os problemas de unicode é usar strings
> > unicode (ex: u'É uma string com acentos').
>
> IMO, o problema não são as strings ASCII mas o fato de as etiquetas estarem em
> português. O "correto" é que esteja tudo em inglês e a tradução no i18n, mesmo
> na localização.
>
> A localização espanhola usa essa prática:
>
> http://bazaar.launchpad.net/~openerp-spain-team/openerp-
> spain/6.1/view/head:/l10n_es_partner/partner_es.py

Ola Carlos,

isso depende de cada coisa. As vezes tem coisas que a gente bota na
localizaçao hoje mas que depois tem vocaçao a ser integrado no core do
OpenERP. Talvez por examplo serio caso daquele flag que fala que a base do
ICMS é feita com o imposto incluido por examplo. Talvez seja tambem o caso
da operaçao fiscal, categoria de operaçao fiscal, NCM etc...
Nesses casos, tem que ser ingles. Nisso temos que pensar bastante sobre a
tendencia a usar varias localizaçoes ou pelos menos core de localizaçoes
juntos no mesmo ERP. E uma necessidade crescente no mundo das empresas nao
ter barreiras nationais. Isso so é possivel se a dinamica é essa integraçao
progressiva das especificidade de localizaçoes em abstraçoes compativeis
com varias localizaçoes.

O modelo de negocio da OpenERP SA tambem é de oferescer suporte de nivel 2
e de fazer um outsource disso na India. Imagina que alguem parceiro ou
cliente quer ter um banco ou um modulo migrado pela OpenERP SA, fica menos
dificil se as coisas estao em ingles.

Agora coisas que sao totalmente especificas do Brasil e vao ficar
especificas como o calculo da ST X, ai sim, realmente da para ser em
portugues.

Atts.

2013/6/12 Carlos Almeida <email address hidden>

> A localização BR é para ser usada mesmo só no Brasil, pelo que apesar de
> defender a abordagem de desenvolver tudo em Inglês e traduzir, sou
> inclinado a concordar com o Leonardo.
>
> No entanto módulos ou código que possam ou venham a ser usados noutras
> localizações deverão ser feitos com expressões inglesas.
>
> > > O jeito mais simples de solucionar os problemas de unicode é usar
> strings
> > > unicode (ex: u'É uma string com acentos').
> >
> > IMO, o problema não são as strings ASCII mas o fato de as etiquetas
> estarem em
> > português. O "correto" é que esteja tudo em inglês e a tradução no i18n,
> mesmo
> > na localização.
> >
> > A localização espanhola usa essa prática:
> >
> > http://bazaar.launchpad.net/~openerp-spain-team/openerp-
> > spain/6.1/view/head:/l10n_es_partner/partner_es.py
> --
>
> https://code.launchpad.net/~renatonlima/openerp.pt-br-localiz/l10n_br_base_i18n/+merge/114481
> Your team OpenERP Brazil Team is subscribed to branch
> lp:openerp.pt-br-localiz/6.1.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-brazil-team
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~openerp-brazil-team
> More help : https://help.launchpad.net/ListHelp
>