Usar I18n

[cesarjr]

Olá pessoal!

Eu gostaria de limpar um pouco mais o código tirando os títulos dos campos e outros de dentro do fonte.

Na minha opinião, isso ficaria melhor internacionalizado. O código ficaria menos poluído e traria até flexibilidade de uso pra gem.

Por exemplo, se alguém não concordar que tal campo não deveria se chamar "XXX", basta ele mudar no yaml ao seu bel prazer.

Segue um exemplo de um projeto internacionalizado.

https://github.com/plataformatec/devise/blob/master/config/locales/en.yml

A minha pergunta é:

Posso fazer? As chances são boas da modificação ser aceita?

É que é uma mudança "meio grande" pra enviar como proposta de pull request e ela ser rejeitada.

Aguardo retorno para proceder com a mudança.

[ereboucas]

Olá Cezinha,

faz sentido falarmos de internacionalização de DANFE ou DACTE? São documentos emitidos e válidos no Brasil, não vejo por que pensar em mais de uma língua.

Abs!

Em 4 de fevereiro de 2014 08:28, Cezinha Anjos notifications@github.comescreveu:

Olá pessoal!

Eu gostaria de limpar um pouco mais o código tirando os títulos dos campos e outros de dentro do fonte.

Na minha opinião, isso ficaria melhor internacionalizado. O código ficaria menos poluído e traria até flexibilidade de uso pra gem.

Por exemplo, se alguém não concordar que tal campo não deveria se chamar "XXX", basta ele mudar no yaml ao seu bel prazer.

Segue um exemplo de um projeto internacionalizado.

https://github.com/plataformatec/devise/blob/master/config/locales/en.yml

A minha pergunta é:

Posso fazer? As chances são boas da modificação ser aceita?

É que é uma mudança "meio grande" pra enviar como proposta de pull request e ela ser rejeitada.

Aguardo retorno para proceder com a mudança.

Reply to this email directly or view it on GitHubhttps://github.com/taxweb/ruby_danfe/issues/22 .

[cesarjr]

Olá?!

Na realidade não é nem pelo fato de flexibilizar para outra língua, mas sim, em nossa própria língua.

Por exemplo:

Nós temos um campo chamado CST. Alguns gostam de plotar CST/CSOSN. Outros gostam de plotar somente CST, outros ainda plotam CST para o regime normal e CSOSN para o Simples Nacional.

Um outro fato que eu acho bem válido e que, pra falar a verdade, é o meu motivador, é a limpeza do código.

A gente poderia começar a tirar um pouco deste português de dentro do fonte. Tá uma mistura de código em Inglês e expressões em português. Se a gente isolasse essas expressões seria melhor.

Segue abaixo o conselho de um cara que eu respeito bastante:

http://www.akitaonrails.com/2013/03/24/quais-sao-algumas-das-piores-praticas-para-aplicacoes-ruby-on-rails--2#.UvDiyWRDvE0

e

http://www.akitaonrails.com/2012/07/14/internationalizacao-i18n-minima-em-rails-3-2-parte-2#twitterbootstrap

Os fontes estão com aqueles #encoding utf-8 que em teoria não precisaria ter.

Aguardo consideração.

[HenriqueLacerda]

ereboucas,

A internacionalização que o Cesar está falando é no sentido padronizar os textos em um arquivo .yml . Tornando mais fácil a manutenção/modificação desses textos.

Cesar, Não sei se seria um bom investimento de tempo fazer essa modificação, já que esses textos são padronizados e não mudarão(ou mudarão muito pouco).

[cesarjr]

Olá @HenriqueLacerda

Pelo tempo... não esquenta. Aqui na ASSEINFO nós estamos bastantes empolgados com o projeto e estamos dispostos a investir. Quando eu não estou codificando pra ele, o @fabriciodaroscijr está. É o mínimo de contribuição que entendemos que devemos dar, já que está nos poupando o trabalho de ter que fazer tudo do zero.

Só preciso saber mesmo é que o nosso trabalho não será sumariamente rejeitado.

O benefício que eu vejo é a clareza no fonte. Hoje tá tudo muito misturado.

Aguardo considerações.

[ereboucas]

Entendo a motivação da manutenção e clareza. Porém fazer isso estará, no meu ponto de vista, indo no sentido contrário. Veja que estamos falando de um projeto para gerar um documento oficial baseado em padrão documentado em língua portuguesa. Não faz sentido seguirmos "melhores práticas" de deixarmos o código todo em inglês (como sugere o Akita). Temos que facilitar a manutenção a partir do Manual do Contribuinte e não "agradar" escritores de livros.

No entanto, se estão com tempo e querem fazer, fiquem à vontade. Só criem chaves em português, ok?

Saudações!

Em 4 de fevereiro de 2014 08:54, Cezinha Anjos notifications@github.comescreveu:

Olá @HenriqueLacerda https://github.com/HenriqueLacerda

Pelo tempo... não esquenta. Aqui na ASSEINFO nós estamos bastantes empolgados com o projeto e estamos dispostos a investir. Quando eu não estou codificando pra ele, o @fabriciodaroscijrhttps://github.com/fabriciodaroscijrestá. É o mínimo de contribuição que entendemos que devemos dar, já que está nos poupando o trabalho de ter que fazer tudo do zero.

Só preciso saber mesmo é que o nosso trabalho não será sumariamente rejeitado.

O benefício que eu vejo é a clareza no fonte. Hoje tá tudo muito misturado.

Aguardo considerações.

Reply to this email directly or view it on GitHubhttps://github.com/taxweb/ruby_danfe/issues/22#issuecomment-34052587 .

[cesarjr]

Olá @ereboucas !

Na realidade não é que a gente não tem nada pra fazer. Pelo contrário... estamos atulhados de trabalho. É que eu vi um benefício real para o projeto.

Sobre as chaves, a minha ideia seria usar as mesmas tags do XML. Assim, no futuro poderia ser criado até mesmo helpers que facilitassem a plotagem do campo.

Sobre a questão do Akita, na realidade ele não é escritor, mas é um excelente programador. Ele foi um dos caras que popularizou o ruby aqui no Brasil. Aqui na empresa já tem um tempo que a gente não mistura Pt com En nos fontes. A leitura fica fluída. É como se você estivesse lendo uma única língua.

Eu respeito o seu ponto de vista, mas acho que algumas coisas já estão meio misturadas no projeto. Um exemplo disso é o readme. Ele estava escrito em En e eu só continuei o trabalho em En. Outro exemplo são os próprios commits. Alguns estão em En e outros em Pt.

O meu ponto de vista é que se você traz padrões para o código, facilita a comunicação com todos.

Mas é só minha opinião. Entendo se a ideia não for aceita ou bem vista. Vocês tem todo o direito de não aceitá-la, assim como nós também temos o direito de escolher contribuir ou não. Talvez a gente está na contra-mão dos objetivos do projeto e isso não é legal nem pra gente e nem pra vocês. Peço desculpas se em algum momento pareci indelicado. Só não vou deixar de expor a minha opinião.

Muito obrigado.

[ereboucas]

Vamos ser práticos e ver um exemplo:

danfe_generator.rb:132

@pdf.ibox 0.85, 9.02, 0.25, 14.90, "RAZÃO SOCIAL", @xml['transporta/xNome']

por

@pdf.ibox 0.85, 9.02, 0.25, 14.90, t(:x06), @xml['transporta/xNome']

e no pt-br.yml

x06: "RAZÃO SOCIAL"

É isso?

Em 4 de fevereiro de 2014 09:27, Cezinha Anjos notifications@github.comescreveu:

Olá @ereboucas https://github.com/ereboucas !

Na realidade não é que a gente não tem nada pra fazer. Pelo contrário... estamos atulhados de trabalho. É que eu vi um benefício real para o projeto.

Sobre as chaves, a minha ideia seria usar as mesmas tags do XML. Assim, no futuro poderia ser criado até mesmo helpers que facilitassem a plotagem do campo.

Sobre a questão do Akita, na realidade ele não é escritor, mas é um excelente programador. Ele foi um dos caras que popularizou o ruby aqui no Brasil. Aqui na empresa já tem um tempo que a gente não mistura Pt com En nos fontes. A leitura fica fluída. É como se você estivesse lendo uma única língua.

Eu respeito o seu ponto de vista, mas acho que algumas coisas já estão meio misturadas no projeto. Um exemplo disso é o readme. Ele estava escrito em En e eu só continuei o trabalho em En. Outro exemplo são os próprios commits. Alguns estão em En e outros em Pt.

O meu ponto de vista é que se você traz padrões para o código, facilita a comunicação com todos.

Mas é só minha opinião. Entendo se a ideia não for aceita ou bem vista. Vocês tem todo o direito de não aceitá-la, assim como nós também temos o direito de escolher contribuir ou não. Talvez a gente está na contra-mão dos objetivos do projeto e isso não é legal nem pra gente e nem pra vocês. Peço desculpas se em algum momento pareci indelicado. Só não vou deixar de expor a minha opinião.

Muito obrigado.

Reply to this email directly or view it on GitHubhttps://github.com/taxweb/ruby_danfe/issues/22#issuecomment-34054517 .

[cesarjr]

Quase lá! Acho que seria algo assim:

No pt-br.yml:

ruby_danfe
  transporta
    xNome: RAZÃO SOCIAL

No danfe_generator.rb:132

@pdf.ibox 0.85, 9.02, 0.25, 14.90, t("transporta.xNome"), @xml['transporta/xNome']

Para o futuro:

@pdf.ibox_labeled 0.85, 9.02, 0.25, 14.90, "transporta.xNome"

Essa é a minha sugestão.

Aguardo considerações.

[ereboucas]

Ok, de acordo.

2014-02-04 Cezinha Anjos notifications@github.com:

Quase lá! Acho que seria algo assim:

No pt-br.yml:

ruby_danfe transporta xNome: RAZÃO SOCIAL

No danfe_generator.rb:132

@pdf.ibox 0.85, 9.02, 0.25, 14.90, t("transporta.xNome"), @xmlhttps://github.com/xml ['transporta/xNome']

Para o futuro:

@pdf.ibox_labeled 0.85, 9.02, 0.25, 14.90, "transporta.xNome"

Essa é a minha sugestão.

Aguardo considerações.

Reply to this email directly or view it on GitHubhttps://github.com/taxweb/ruby_danfe/issues/22#issuecomment-34056866 .

[cesarjr]

Show de bola @ereboucas !

Vou esperar vocês aprovarem ou reprovarem os pull requests do @fabriciodaroscijr pra não complicar depois no merge.

Como esta será uma daquelas mudanças radicais no fonte, quanto mais coisas estiverem integradas, melhor para o pessoal que submete pull request. Assim eles não precisam ficar sincronizando e fundido código atoa.

Muito obrigado!