This project is archived and is in readonly mode.

I18n locale may be reset to :en if called from a plugin/gem

#5145

How to reproduce :

Create a new Rails 3 beta 4 app, set the default_locale to :fr (or whatever) in application.rb (and put the correct yml file).
Run a rails console. Check that I18n.locale is the right default_locale you've just set.

Now create a fake plugin : create a folder "foo" in vendor/plugins, create the file vendor/plugins/foo/init.rb with a call to I18n.translate in it, like :

  I18n.t("bar")

Run the Rails console in development mode and in production mode. In my case the locale is reset to :en.

This is a problem because many gems and plugins use I18n.t for example translating error messages in models...

Note : this problem does not occur in Rails 2.3.x.

Reported by Nicolas Blanco · July 18th, 2010 @ 03:43 PM

Activity

Falk Pauser
I am using rails3-rc1 and have a similar issue. In config/application.rb I set config.i18n.default_locale = :de after putting a de.yml into "config/locales". In development-mode everything is just fine, I18n.locale and I18n.default_locale return :de in rails-console. At the production-server I18n.default_locale is :de too, but I18n.locale gives :en without any obvious reason...

August 18th, 2010 @ 04:47 PM
Falk Pauser
Just tried the current "3-0-stable" branch - same effect.

August 19th, 2010 @ 09:49 AM
Nicolas Blanco
The only workaround I've found in to set the locale again in an initializer... bad...

August 21st, 2010 @ 07:47 PM
cabgfx
Hi,
I've experienced the same problem, with Rails 3.0.0.
My app also bundles authlogic 2.1.6, which seems to cause the effect.

I've fixed it for now, by brute-forcing config.i18n.locale = :da, in /config/environments/production.rb.
I'd assume this shouldn't be necessary, since I already have config.i18n.default_locale set in /config/application.rb ?

This issue has also been discussed on the Google Group

September 11th, 2010 @ 05:14 PM
Robert Pankowecki
- Tag changed from default_locale, i18n to available_locales, default_locale, gem, i18n, plugin
```
#vendor/plugins/foo/init.rb 
puts I18n.available_locales.inspect
puts I18n.locale
```
When 'rails c' is run you can see:
```
[:en]
en
```
That is because you try to translate sth in plugin init.rb file and the translation is done until I18n configuration is fully loaded.

Furthermore; using rails c shows that:
```
puts I18n.available_locales.inspect
[:en]
puts I18n.backend.available_locales
en
de
```
the locale' andavailable_locales' are cached in the I18n library the first time they are used as you can see.

In other words: Gem or plugin should not try to translate anything until all initializers are run. I would say it is gem/plugin or I18n fault, not rails.
September 11th, 2010 @ 07:52 PM
David Trasbo
- Assigned user changed from Sven Fuchs to Rohit Arondekar
I definitely agree with Robert. It's not Rails' fault and this can almost certainly be closed.

September 11th, 2010 @ 10:10 PM
Rohit Arondekar
- State changed from new to invalid
- Importance changed from to Low
September 12th, 2010 @ 01:42 PM
Rodrigo Rosenfeld Rosas
This is a sad attitude. This remembers me the way Grails developers treat their issues. They provide GORM for ORM but rely on Hibernate and when there is some issue with GORM the mark the issue as "won't fix" because this is Hibernate fault, not Grails' as if the user had the chance to use another framework with GORM.

I18n is the only supported way of adding internationalization support to Rails. It just happens that it is a separate gem that Rails is taking advantage of, but if i18n is broken in Rails it doesn't mean it is not Rails fault and that issues should be marked as invalid. If the i18n gem is not good enough for Rails (which is not the case), then should think in another way of getting i18n in Rails. Not simply telling it doesn't care about i18n and it won't try to fix any related issues even if the source isn't exactly in rails repository.

Besides that, it is not clear to me that this is a i18n issue instead of a Rails one. I still think the problem is in Rails, not on i18n itself. Rails should assure the order in which the calls are done to ensure the plugins will have i18n loaded before their initialization code gets executed...

September 12th, 2010 @ 02:45 PM
Rohit Arondekar
- State changed from invalid to open
- Assigned user changed from Rohit Arondekar to Sven Fuchs
Rodrigo, firstly I'm not a core member so the issue is not closed forever! :)

Secondly, I apologize, I did rush through the ticket. Also I usually leave a friendly "closing now, if you still think this is an issue then leave a comment and I'll reopen it" comment while closing an issue.

Assigning ticket to an author of the i18n gem for confirmation as to whether this is a i18n issue, gem/plugin issue or an issue with Rails.

In the mean time if it's at all possible can you try writing a failing test for rails? That's usually the best way to demonstrate that it's a Rails issue.

September 12th, 2010 @ 03:00 PM
Rodrigo Rosenfeld Rosas
Hi Rohit, thank you for reopening the ticket.

I've actually isolated the problem in June 14 (one day after my birthday :) ), in the Google Group discussion commented by cabgfx. We don't even need any plugin for reproducing the issue.

I'm just not sure how to write some test of this kind. If someone could suggest me any approach (what subproject, and how to simulate Rails loading, preferencially in a fast way that won't impact too much on test run speed) I could try to write one...

September 12th, 2010 @ 03:13 PM
Ryan Bigg
- Tag cleared.
Automatic cleanup of spam.

October 9th, 2010 @ 09:55 PM
Roger Campos
This commit from Saimon Moore maybe should fix this ticket.

February 25th, 2011 @ 10:49 PM