Migrando do ruby gettext para o ruby i18n

[Bráulio Bhavamitra]

2013/5/6 Antonio Terceiro <terceiro at colivre.coop.br>

> On Sun, May 05, 2013 at 10:56:51PM -0300, Bráulio Bhavamitra wrote:
> > Olá comunidade,
> >
> > Desde o rails 2.2 foi incorporado o ruby i18n como sistema padrão de
> > traduções. O sistema traz inúmeras vantagens em relação ao ruby gettext,
> > antigo sistema usado em aplicações rails e ainda hoje no noosfero:
>
> Essa não é a primeira vez que eu vejo isso ser levantado. O Noosfero
> *não* utiliza ruby-gettext (i.e.
> http://www.yotabanana.com/hiki/ruby-gettext.html) no runtime faz
> *muito* tempo. o ruby-gettext é utilizado apenas para extrair as strings
> para os arquivos PO, em tempo de desenvolvimento.
>
> Em tempo de execução o Noosfero utiliza uma biblioteca chamada
> FastGettext, que se integra ao I18n utilizado pelo Rails, mas fornece a
> interface igual ao GNU gettext, e consequentemente ao ruby-gettext (i.e.
> _("Texto")).
>
Sim, em tempo de execução e em desenvolvimento o outro. O que importa é que
em ambos o padrão e as funcionalidades são do gettext

>
> > - Texto em inglês separado do código,
>
> isso também significa um código de interface de usuário que não é
> auto-contido, e pra mim isso é uma grande desvantagem.
>
Para o desenvolvedor pode realmente parecer uma desvantagem. Mas pelo bem
do software, é melhor dar neste ponto uma vantagem ao redator, e o
programador pode se adaptar a dinamica de colocar os textos fora do código.

>
> > permitindo um olhar centralizado e
> > cuidadoso de um redator para melhorar a comunicação da interface
>
> então você acha que com o texto separado um redator vai melhorar a
> comunicação da interface, mas sem acessar o código da interface? :-)
>
Exato, para um redator nao faz sentido ver o código, só a tela em execução.

>
> > - Muito mais fácil de manter: o rake updatepo cria conflitos muito
> difíceis
> > de se resolver no git
>
> arquivos po não foram feitos pra se usar diff. Não se passa diff de
> arquivos po, exceto quando se está fazendo mudanças muito pequenas. Em
> geral, updates não-triviais em arquivos po devem ser feitos simplesmente
> enviando o arquivo todo comprimido.
>
> > - Melhor internacionalização de moedas, datas, etc
> > - Melhor integração com formulários
>
> Não tem necessidade de compilação das traduções (com o rake makemo)

>  > - Melhor performance
>
> Melhor baseado em quais fatos?
>
Tinha visto há muito tempo um benchmark disto, mas não o encontrei
novamente. A performance
é um ponto a ser considerado, mas o i18n do ruby/rails também traz muitas
vantagens.

Vale ver as comparações que outras pessoas fizeram. Deixo uma:
https://groups.google.com/forum/?fromgroups=#!topic/rails-i18n/d5NgDfgZ1gw

>
> > Por conta dos conflitos no git no desenvolvimento do plugin de coletivos
> de
> > consumo, que chegaram a tomar uma quantidade de tempo muito grande,
> > decidimos investir (eu e hugo) na migração do ruby gettext para o ruby
> i18n.
> >
> > Tentamos fazer de maneira mais automática possível, através do seguinte
> > script:
> > https://gist.github.com/brauliobo/5512890
> >
> > Este script cria as chaves no config/locales/en.yml e nas respectivas
> > traduções usando as traduções já existentes nos arquivos .po, alterando
> os
> > arquivos de código fonte com as chamadas t() ao invés de _() com as
> chaves
> > criadas.
> >
> > Há algumas limitações, mas no caso do plugin dos coletivos quase 100% do
> > código foi convertido automaticamente sem problemas. A conversão manual
> > deve ser feita para strings multinhas, tradução com plural e traduções no
> > contexto de classe.
>
> Antes de se dar a essa trabalho, vocês poderiam ter perguntado se não
> tem uma forma mais fácil.
>
> Por exemplo, não é difícil alterar o Noosfero pra utilizar um arquivo PO
> separado pra cada plugin, o que faria o problema que motivou tudo isso
> desaparecer.
>
Continuar usando os POs não resolve o problema dos conflitos gerado pela
extração das strings com o updatepo, ou ter q inserir na mão a linha do
código e a string copiada do código.

Não acho que o noosfero como um todo deva usar apenas o po ou o i18n ou
qualquer outro.
Acho que a diversidade neste ponto não atrapalha a produtividade. O que
quis colocar é que o i18n traz recursos muito interessantes que devem ser
aproveitados.

abraços,
bráulio

>
> --
> Antonio Terceiro <terceiro at colivre.coop.br>
> Colivre - Cooperativa de Tecnologias Livres
> http://www.colivre.coop.br/
>
>
>
> _______________________________________________
> Noosfero-br mailing list
> Noosfero-br at listas.softwarelivre.org
> http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/noosfero-br
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.softwarelivre.org/pipermail/noosfero-br/attachments/20130506/699b0065/attachment.html>