fix(dashboard): render pagination in the dashboard's own locale

[AnjanJ]

Fixes #148.

The bug

The dashboard rendered Pagy labels in whatever language the host app last used — Russian on one refresh, Portuguese on the next.

Root cause

Pagy stores its locale in a thread-local it never resets (pagy-43.6.1/lib/pagy/modules/i18n/i18n.rb:24-31):

# Set a valid locale or nil for the duration of a single request. Avoid errors/logging.
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

def locale
  Thread.current[:pagy_locale] || 'en'
end

That comment is aspirational — there is no around_action, railtie hook, or ensure anywhere in the gem. So under Puma:

1. Host app request on thread A sets Pagy::I18n.locale = "ru"
2. Thread A returns to the pool still holding "ru"
3. A dashboard request lands on thread A → renders Russian
4. Next one lands on thread B, which last served pt → Portuguese

The language is a function of which pooled thread picked up the request, which is why it looked random and changed on refresh.

Reproduction

Deterministic, no Rails app needed — set the locale on a thread, then render info_tag on that same thread:

host set ru  -> Всего 100 записей, показаны с 1 по 25
host set pt  -> Mostrando itens 1-25 de um total de 100
host set fr  -> Affichage des éléments 1 à 25 sur 100 au total
host set es  -> Mostrando ítems 1-25 de 100 en total

Identical dashboard code, four languages.

The fix

Pagy 43 has no per-call locale option (verified across every helper signature), so set-and-restore around the request is the only correct approach. Two details are load-bearing:

• around_action, not before_action. A before_action would strand the dashboard's locale on the thread for the host app's next request — the same leak pointing the other way. The ensure also covers the rescue_from handlers, which still render through the view layer.
• Read the previous value from Thread.current, not Pagy::I18n.locale. The getter coerces nil → "en", so restoring through it would stamp "en" onto a thread that started clean, making the dashboard a source of the very leak it fixes.

config.dashboard_locale

Added (default "en") rather than hardcoding English, so the mechanism is already in place for translating the rest of the dashboard later. Today it only affects Pagy labels; every other string in the UI is still English.

Resolution is defensive. An unknown lowercase tag ("xx") warns and falls back inside Pagy, but a wrong-cased one ("EN") passes Pagy's LOCALE_PATTERN, finds en.yml, then reads a nil dictionary because the YAML's top-level key is lowercase — raising NoMethodError mid-render on every dashboard page. Values are matched case-insensitively against the shipped dictionaries and fall back to "en", so a config typo cannot take the dashboard down.

Note for the reporter

The workaround in #148 has this same bug in the opposite direction — the admin controller sets Pagy::I18n.locale in a before_action and never restores it, leaking "en" into the public site's threads. The around_action/ensure pattern here fixes that class of bug.

Test plan

• RSpec: 3648 examples, 0 failures (+8)
• RuboCop: 414 files, no offenses
• Verified the two core specs fail with the around_action removed and pass with it, including the exact reported symptom
• Locale resolution checked against nil, "", " ", en, EN, fr, FR, ru, pt-BR, pt-br, PT-BR, zh-CN, :fr, "xx", "not-a-locale"

🤖 Generated with Claude Code