Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can't modify frozen Hash: {} (FrozenError) #613

Closed
lavrovdv opened this issue Feb 3, 2022 · 7 comments
Closed

can't modify frozen Hash: {} (FrozenError) #613

lavrovdv opened this issue Feb 3, 2022 · 7 comments
Labels
Milestone

Comments

@lavrovdv
Copy link

lavrovdv commented Feb 3, 2022

Default parameter options = EMPTY_HASH in method def resolve(locale, object, subject, options = EMPTY_HASH) is a frozen Hash, options.delete(:fallback_in_progress) raise can't modify frozen Hash: {} (FrozenError)

options.delete(:fallback_in_progress)

@radar
Copy link
Collaborator

radar commented Feb 3, 2022

@lavrovdv Thank you for filing this issue. How can I replicate this issue on a new application myself? Could you please provide exact steps to reproduce.

@lavrovdv
Copy link
Author

lavrovdv commented Feb 4, 2022

I got this error in rails app in production env.

Loading production environment (Rails 6.1.4.4)
irb(main):001:0> I18n.t!(:"date.month_names", :locale => :ru, :format => "%B %Y")
.../bundle/ruby/3.0.0/gems/i18n-1.9.1/lib/i18n/backend/fallbacks.rb:72:in `delete': can't modify frozen Hash: {} (FrozenError)

@radar
Copy link
Collaborator

radar commented Feb 8, 2022

I'm currently unable to reproduce this issue in any Rails application of mine. Could you please create a Rails app repo on GitHub and share it here?

@radar radar added the no-repro label Feb 8, 2022
@yaroslav
Copy link
Collaborator

I am having the exact same error with the same locale; persists in production, but can't reproduce in the local environment so far.

It started after the update to Rails 6.0.4.6 which updated i18n to 1.9.1.

Mine dies on things as simple as l(from, format: '%d %B %Y').

    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/fallbacks.rb:72 :in `delete`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/fallbacks.rb:72 :in `block in resolve`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/fallbacks.rb:71 :in `catch`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/fallbacks.rb:71 :in `resolve`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/base.rb:147 :in `block in resolve`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/base.rb:141 :in `catch`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/base.rb:141 :in `resolve`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/fallbacks.rb:69 :in `resolve`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/base.rb:35 :in `translate`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/fallbacks.rb:50 :in `block (2 levels) in translate`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/fallbacks.rb:49 :in `catch`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/fallbacks.rb:49 :in `block in translate`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/fallbacks.rb:47 :in `each`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/fallbacks.rb:47 :in `translate`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n.rb:221 :in `block in translate`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n.rb:217 :in `catch`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n.rb:217 :in `translate`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n.rb:236 :in `translate!`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/base.rb:277 :in `block in translate_localization_format`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/base.rb:269 :in `gsub`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/base.rb:269 :in `translate_localization_format`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n/backend/base.rb:85 :in `localize`
    [GEM_ROOT]/gems/i18n-1.9.1/lib/i18n.rb:316 :in `localize`

@yaroslav
Copy link
Collaborator

Freezing i18n to ~1.8 solved the issue for me.

Now, both me and Dmitry @lavrovdv seem to have the same locale, :ru. That means that either Dmitry uses my russian gem that has not been touched in years, and I mean years unfortunately (although IIRC the API did not change much), or they use a .yml+.rb extract from it that has been shared around as Russian localization for Rails. My app uses the gem.

Unfortunately, I have not been able to pinpoint the issue to the gem exactly: everything works in my local environment, but dies in production. The gem does not hack or overload I18n in anyway, just wraps around it. Here are the localization files supplied: https://github.com/yaroslav/russian/tree/master/lib/russian/locale.

You can see that the datetime (as well as plulralization) is actually a lambda: https://github.com/yaroslav/russian/blob/master/lib/russian/locale/datetime.rb, which is important for Cyrillic languages and was working more or less as intended for almost 11 years now.

@Somestuffman
Copy link

Also having the same issue with date localization after updating to 1.9.1. Seems #622 fixes the problem.

@radar radar added this to the 1.10 milestone Feb 14, 2022
@radar
Copy link
Collaborator

radar commented Feb 14, 2022

I18n 1.10.0 has just been released, and I think it'll fix this problem.

@radar radar closed this as completed Feb 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants