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 use I18n for confirmation messages #649

Open
spatarel opened this issue Oct 6, 2020 · 3 comments
Open

Can't use I18n for confirmation messages #649

spatarel opened this issue Oct 6, 2020 · 3 comments

Comments

@spatarel
Copy link
Contributor

spatarel commented Oct 6, 2020

How to replicate:

#/app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  before_action :set_locale

  def set_locale
    if request.subdomains.first == 'ro'
      I18n.locale = 'ro'
    elsif request.subdomains.first == 'en'
      I18n.locale = 'en'
    else
      I18n.locale = 'en'
    end
  end
end

#/app/controllers/some_table_controller.rb
class SomeTableController < ApplicationController
  active_scaffold :some_table do |conf|
    conf.action_links.add :some_action,
      type: :collection, crud_type: :update,
      method: :put, position: false,
      confirm: I18n.t('some_table.some_action.confirmation_message')
  end
end

Expected behaviour: The confirmation message should be translated in ro or en, depdending on the subdomain.

Actual behaviour: The confirmation message is translated in the default language.

Why is this happening? set_locale method runs after active_scaffold is configured.

How to fix it?

Option 1: Allow confirm parameter to be either a string or a Proc. Then this code should work:

#/active_scaffold/lib/active_scaffold/data_structures/action_link.rb
    def confirm(label = '')
      return @confirm if !confirm? || @confirm.is_a?(String)
      return @confirm.call if !confirm? || @confirm.is_a?(Proc) # this line is new
      ActiveScaffold::Registry.cache(:translations, @confirm) { as_(@confirm) } % {label: label}
    end

#/app/controllers/some_table_controller.rb
class SomeTableController < ApplicationController
  active_scaffold :some_table do |conf|
    conf.action_links.add :some_action,
      type: :collection, crud_type: :update,
      method: :put, position: false,
      confirm: -> { I18n.t('some_table.some_action.confirmation_message') } # this line is changed
  end
end

Option 2: Perhaps there is some other way of sending that confirmation message. But I don't understand what this line does:
ActiveScaffold::Registry.cache(:translations, @confirm) { as_(@confirm) } % {label: label}

Conclusion: I would choose Option 1, since even if there is already support for Option 2, Option 1 offers more flexibility.

@scambra
Copy link
Member

scambra commented Oct 6, 2020

If you put I18n.t in active_scaffold block, is evaluated when app starts, so language doesn't change. You must set a symbol there, then active_scaffold will translate it, it will look for symbol under active_scaffold scope.

ActiveScaffold::Registry.cache is caching translation for current action, because when you have a long list, with many rows with same actions, it's faster to translate one and then use interpolation to replace %{label}, than translate many times.

@spatarel
Copy link
Contributor Author

spatarel commented Oct 6, 2020

It works like a charm! Thank you!

I will write down what I did, in case other people are interested in the topic:

#/config/locales/ro.yml
ro:
  active_scaffold:
    some_action_confirmation: 'RO message'

#/config/locales/en.yml
en:
  active_scaffold:
    some_action_confirmation: 'EN message'

#/app/controllers/some_table_controller.rb
class SomeTableController < ApplicationController
  active_scaffold :some_table do |conf|
    conf.action_links.add :some_action,
      type: :collection, crud_type: :update,
      method: :put, position: false,
      confirm: :some_action_confirmation
  end
end

I suppose there's no chance for Proc support, right?

@scambra
Copy link
Member

scambra commented Oct 7, 2020

I could accept a patch supporting proc, but I don't know if it would be any improvement

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants