This project is archived and is in readonly mode.

#5145 open
Nicolas Blanco

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

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

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.

Comments and changes to this ticket

  • Falk Pauser

    Falk Pauser August 18th, 2010 @ 04:47 PM

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

  • Falk Pauser

    Falk Pauser August 19th, 2010 @ 09:49 AM

    Just tried the current "3-0-stable" branch - same effect.

  • Nicolas Blanco

    Nicolas Blanco August 21st, 2010 @ 07:47 PM

    The only workaround I've found in to set the locale again in an initializer... bad...

  • cabgfx

    cabgfx September 11th, 2010 @ 05:14 PM

    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

  • Robert Pankowecki

    Robert Pankowecki September 11th, 2010 @ 07:52 PM

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

  • David Trasbo

    David Trasbo September 11th, 2010 @ 10:10 PM

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

  • Rohit Arondekar

    Rohit Arondekar September 12th, 2010 @ 01:42 PM

    • State changed from “new” to “invalid”
    • Importance changed from “” to “Low”
  • Rodrigo Rosenfeld Rosas

    Rodrigo Rosenfeld Rosas September 12th, 2010 @ 02:45 PM

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

  • Rohit Arondekar

    Rohit Arondekar September 12th, 2010 @ 03:00 PM

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

  • Rodrigo Rosenfeld Rosas

    Rodrigo Rosenfeld Rosas September 12th, 2010 @ 03:13 PM

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

  • Ryan Bigg

    Ryan Bigg October 9th, 2010 @ 09:55 PM

    • Tag cleared.

    Automatic cleanup of spam.

  • Roger Campos

    Roger Campos February 25th, 2011 @ 10:49 PM

    This commit from Saimon Moore maybe should fix this ticket.

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

Pages