activeadmin/activeadminPublic

NotificationsYou must be signed in to change notification settings
Fork3.3k
Star9.7k

Dynamic I18n labels in Active Admin filters render as Proc objects instead of translated strings#8718

Unanswered

bbasanta238 asked this question inHelp

bbasanta238

May 10, 2025

· 1 comments· 10 replies

Return to top

Discussion options

bbasanta238
May 10, 2025

Active Admin Version: [3.3]
Rails Version: [7.2]

Description:
The label for a filter in Active Admin, when attempting to be dynamically translated using either aProc or a lambda (->) that callsI18n.t, does not update dynamically when the application's locale is changed at runtime. Instead of the translated string, the rawProc or lambda object is rendered as the filter label in the user interface until the Rails server is restarted.

Steps to Reproduce:
Using a Proc:

ActiveAdmin.registerItemdofilter:status,as::select,collection:Item.statuses.keys,label:proc{I18n.t("activerecord.attributes.item.status")}end

Using a Lambda:

ActiveAdmin.registerItemdofilter:status,as::select,collection:Item.statuses.keys,label:->{I18n.t("activerecord.attributes.item.status")}end

Expected Behavior:
The filter label defined using aProc or a lambda (->) that callsI18n.t should be evaluated on each request and update dynamically to reflect the currently selected locale.

Actual Behavior:
The filter label is rendered as the string representation of theProc or lambda object.

You must be logged in to vote

Replies: 1 comment 10 replies

Comment options

tagliala
May 10, 2025
Maintainer

Hello,

To address your question:

Is it documented thatlabel accepts a Proc?
From the available documentation, it doesn't appear to explicitly state thatlabel can accept aProc. If there is documentation or examples to the contrary, sharing them would be helpful.
Is this expected to work because Rails-based applications manage to accept Procs in that way?
While Rails applications typically allow the use ofProc or lambda for dynamic behaviors, I'm not familiar with this approach when it comes to messages. Do you have a reference in Rails' documentation?
What is the application trying to achieve with this approach?
The likely intent is to dynamically translate filter labels based on the current locale. This approach aligns with Rails' I18n patterns, where translations adapt to the application's locale without requiring restarts.

You must be logged in to vote

10 replies

Comment options

tagliala May 12, 2025
Maintainer

Thanks. Found it and I'm able to reproduce

So we have an issues withscopes, the offending line for v3 is:

activeadmin/lib/active_admin/views/components/active_filters_sidebar_content.rb

Line 49 in6234aa4

label=filter.try(:[],:label) ||filter_name.titleize

But this is also an issue on V4

@mgrunberg I'm not very familiar with this part, I'm quite suprised thatlabel does not work for filters in that scenario (returned object are hashes)

Comment options

mgrunberg May 13, 2025
Maintainer

@tagliala I'm not very familiar with this part, but this also took me by surprise.

I did a quick test with the test app on master and label works as expected with ransack predicates. It's just a problem of scopes.

Compared with the offending line you highlighted, ransack predicates (active_filters) label logic is far more complicated and deals with many scenarios.

activeadmin/lib/active_admin/views/components/active_filters_sidebar_content.rb

Line 11 in6234aa4

active_filters=ActiveAdmin::Filters::Active.new(active_admin_config,assigns[:search])

activeadmin/lib/active_admin/views/components/active_filters_sidebar_content.rb

Line 32 in6234aa4

active_filters.filters.each{ |filter|filter_item(filter)}

activeadmin/lib/active_admin/views/components/active_filters_sidebar_content.rb

Lines 39 to 44 in6234aa4

	deffilter_item(filter)
	lifilter.html_optionsdo
	spanfilter.label
	bto_sentence(filter.values.map{ \|v\|pretty_format(v)})
	end
	end

activeadmin/lib/active_admin/filters/active_filter.rb

Lines 27 to 38 in6fcc9d7

	deflabel
	translated_predicate=predicate_name.downcase
	iffilter_label &&filter_label.is_a?(Proc)
	"#{filter_label.call}#{translated_predicate}"
	elsiffilter_label
	"#{filter_label}#{translated_predicate}"
	elsifrelated_class
	"#{related_class_name}#{translated_predicate}"
	else
	"#{attribute_name}#{translated_predicate}"
	end.strip
	end

I can't say why scopes are handled differently.@javierjulio do you have an insight on this?

Comment options

javierjulio May 13, 2025
Maintainer

Sorry, I don't. I do recall changes around this over the years to make improvements so I'm not surprised if some cases are missing or not handled.

Comment options

prashana-sht May 15, 2025

@tagliala @mgrunberg @javierjulio, is there any update on how we can handle the scopes?

Comment options

tagliala May 15, 2025
Maintainer

I think a fix is required, but at the moment I cannot allocate time for a PR.

Also, V4 and V3 are different, so we should have two different fixes. I would investigate why scopes are returned as hashes and then try to submit a PR with specs