Forum: Rails I18n upgrading from Rails 2.0.2 to Rails 3

Hi guys,

I used my rails site for 2 years without any upgrades. But now I want to
upgrade from the first rails 2 version to the newest. I've used rails
2.0.2 with the last globalize version 1.0.2... but now I've to upgrade
to globalize 3.... BUT HOW?!??! I've looked for tutorials, howto's but
it seems that nobody whants to do it?!?

My question: What have I to do to upgrade globalize? (I know the
git-sites of globalize2 and globalize3)
OR HOW have ouy changed your sites completely from globalize to I18n?

thanks in advanced of a stressed user ;-)

On 24 Nov 2010, at 11:58, Guido Holz wrote:

> Hi guys,
>

Hi Guido

> I used my rails site for 2 years without any upgrades. But now I want to
> upgrade from the first rails 2 version to the newest. I've used rails
> 2.0.2 with the last globalize version 1.0.2... but now I've to upgrade
> to globalize 3.... BUT HOW?!??! I've looked for tutorials, howto's but
> it seems that nobody whants to do it?!?
>
> My question: What have I to do to upgrade globalize? (I know the
> git-sites of globalize2 and globalize3)
> OR HOW have ouy changed your sites completely from globalize to I18n?
>

We're just at the tail end of doing this to our site. We've gone to 
2.3.x first, but the principle is the same. You're going to need to go 
through your site and change everywhere you're doing 'foo'.t to 
t('some.namespace.foo'), same for .tn and /. How big a job this is 
depends on the size of your site. I wrote some little tools to help me 
but they're pretty specific to our app. You'll need to decide on 
namespaces, and read up on how I18n works in rails now (the guide is 
great). FWIW we're just using plain I18n, not globalize.

What I did initially was remove the globalize plugin and make some 
monkey patches for .t, .tn, / etc. that just returned the string, 
marking any failing specs as pending. This meant we could upgrade to 
2.3.x and fix everything that needed to be fixed for that before coming 
back to i18n. Once that was done it was a pretty slow job trudging 
through the code, moving stuff to the new format and grabbing the old 
translations to put in the yml.

We settled on a simple schema for keys to start with based on the files 
name and directory. This was so we can easily find where they are when 
we inevitably want to move them around :)

So for example a flash message in the create action in WidgetsController 
e.g.

"widget created".t

would become

t('controllers.widgets.create.success')

And in say app/views/widgets/index.html.haml

%h1= "Widget list".t

would become

%h1= t('views.widgets.index.title')

etc. etc.

We're looking forward to getting everything back together using the key 
based system. We think our translations will improve, not least because 
the translators can reorder the variables now :)

I used the following ack search to get a handle on how big the job was 
initially:

ack --no-color --ignore-dir=vendor --ignore-dir=public --ignore-dir=spec 
"(\.t[^aDehimortuxy]|['\"]\s* / )"

> thanks in advanced of a stressed user ;-)

HTH,

Chris

Hey Chris thanks for your explanation. I thought I could do it without 
rails2 :-(
Anyway... that wasn't what you want to hear. But it should be the best 
way like you did.

cheers guido

On 25 Nov 2010, at 11:22, Guido Holz wrote:

> Hey Chris thanks for your explanation. I thought I could do it without
> rails2 :-(

We made the decision to stay with 2.3.x because we didn't want to go to 
3.0 in one blast. We wanted to be sure which bugs were caused by our 
re-i18n of the site and not have to think about whether they could be 
caused by a rails 3.0 change too. I think it was the right call in the 
end, mainly because rspec 2.0 isn't backwards compatible so we'd have 
been changing the tests and the code at the same time. If you're using a 
different testing framework then you might be ok going straight to 3

Chris