Migrando do ruby gettext para o ruby i18n

[Antonio Terceiro]

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

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

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

> - 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
> - Melhor performance

Melhor baseado em quais fatos?

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

-- 
Antonio Terceiro <terceiro at colivre.coop.br>
Colivre - Cooperativa de Tecnologias Livres
http://www.colivre.coop.br/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://listas.softwarelivre.org/pipermail/noosfero-br/attachments/20130506/fb08e11b/attachment.pgp>