I18n default locale strange behavior in Rails 3 beta 4 (bug?)

[Rodrigo Rosenfeld Rosas]

I could finally isolate the strange issue regarding I18n in my application.

For reproducing it, do the following (using rails 3 beta 4 gem):

rails new i18nproblem

Create these files:

app/models/mymodel.rb

require 'something'
class Mymodel
include Something # comment this line and the issue is gone
end

lib/something.rb

module Something
def self.included(base)
puts I18n.locale
end
end

Change default locale to :'pt-BR' in config/application.rb

Open a console in test environment:

rails c test

> I18n.locale (yields :en)
> I18n.default_locale (yields :"pt-BR")

Commenting the "include Something" line, this strange behavior disappear
(both locale and default_locale returns :'pt-BR')

Is this behavior expected? Am I assuming something wrong? Is it a bug?
Any hints?

Thanks in advance,

Rodrigo.

[rainerfrey]

Sorry for the personal reply, but I was no list member at the time
this was sent, and I can't find another way to respond.

On Jun 15, 4:46 am, Rodrigo Rosenfeld Rosas <rr.ro...@gmail.com>
wrote:

> I could finally isolate the strange issue regarding I18n in my application.

I noticed a very similar problem which I described on the rubyonrails-
talk list in http://groups.google.com/group/rubyonrails-talk/msg/0c99f2d29afcf3aa
In short:
I set config.i18n.default_locale=:de in config/application.rb
in development environment: I18n.default_locale=:de, I18n.locale=:de
and in production environment: I18n.default_locale=:de,
I18n.locale=:en

I use 3.0.0rc2, ruby 1.8.7 and 1.9.2.
it shouldn't

> app/models/mymodel.rb
>
> require 'something'
> class Mymodel
>    include Something # comment this line and the issue is gone
> end
>
> lib/something.rb
>
> module Something
>    def self.included(base)
>      puts I18n.locale
>    end
> end
>
> Change default locale to :'pt-BR' in config/application.rb
>
> Open a console in test environment:
>
> rails c test
>
>  > I18n.locale (yields :en)
>  > I18n.default_locale (yields :"pt-BR")
>
> Commenting the "include Something" line, this strange behavior disappear
> (both locale and default_locale returns :'pt-BR')

I don't have explicit requires in my models, but I use authlogic
(2.1.5), which does require files in the modules that are included in
model classes, and this behavior goes away if I uncomment the
acts_as_authentic call in my user model.

> Is this behavior expected? Am I assuming something wrong? Is it a bug?
> Any hints?

It would be great if these questions could be answered before a Rails
3 final release is out. There isn't necessarily a bug in the rails
source code, but I can hardly believe this behavior is expected or
even intended.
>
> Thanks in advance,
>
> Rodrigo.

Thanks as well
Rainer

[cabgfx]

Hi,
I've had the exact same problem, running Rails 3.0.0 + authlogic 2.1.6

For now, I just fixed it by brute-forcing it in production.rb:
config.i18n.locale = :da

It does feel awkward, though, since config.i18n.default_locale is set
in application.rb.
I'm not really sure what the correct behaviour should be..?

[cabgfx]

FYI: Lighthouse ticket here:
https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/5145-i18n-locale-may-be-reset-to-en-if-called-from-a-plugingem

[Hugo Peixoto]

Hey,

An "easier" workaround would be to write "I18n.default_locale
= :whatever" instead of "config.i18n.default_locale = :whatever".

Nevertheless, the problem seems to be that the modules and classes are
loaded during the eager_load process, while the I18n configuration is
only set on an after_initialize hook.

I18n.locale is called before the config.i18n.default_locale is
propagated to the I18n class. If we take a look at the "locale"
method, we see that it will only check the default_locale once.
This renders the default_locale= call useless.

According to a source code comment located in the activesupport-3.0.0/
lib/active_support/i18n_railtie.rb file, the configuration is set on
an after_initialize hook "since a lot of configuration is still
usually done in application initializers".
To fix this problem, I think that this configuration would need to be
moved to somewhere before the eager_loading, but I don't know if that
is even possible, or how to do it.