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

Feature Request: Setting specific default locale for good job #921

Open
Jay-Schneider opened this issue Apr 11, 2023 · 4 comments
Open

Feature Request: Setting specific default locale for good job #921

Jay-Schneider opened this issue Apr 11, 2023 · 4 comments

Comments

@Jay-Schneider
Copy link
Contributor

Hi there,

while I appreciate the effort that is put into internationalizing the dashboard (most recently #903), I have some issues with GoodJob simply using the default locale configured for the application.

Similar to the description in #889, we also use GoodJob as administrative tooling and it is not end user facing. So even though our application is localized in German, there is no need for the GoodJob dashboard to be in German as well. English would be totally fine.

But the current implementation in combination with us having set config.i18n.default_locale = :de results in the dashboard "trying to be in German" as in the translations are not complete or imperfect. E.g. despite "Klar" being a correct translation for the adjective "clear", the "Clear" filter button (verb) should be something like "Leeren".

If we had the need for it, I would gladly contribute more translations but as explained we would prefer the thoughtfully created english UI over a german one.

So I think there should be the option to configure a good_job.default_locale that may override the i18n.default_locale if set.

What do you think about that?

PS, for others with this concern: I experimented with a workaround using

mount GoodJob::Engine, at: "good_job", defaults: { locale: :en }

in the routes.rb that masks the problem for the time being. But this makes the locale switcher inoperative which is not a nice solution.

@bensheldon
Copy link
Owner

@Jay-Schneider Thanks for opening this issue. I agree that there are lots of painful edges right now with internationalization.

I just pushed up #923 which I think should allow setting a default locale via the routes mount and not break the other locales.

I'd like to keep this as a workaround for now because I think there is an even more painful edge that I don't want to drop people onto...

That painful edge is I18n.available_locales and I18n.enforce_available_locales!. Those are currently application-wide globals that can't be changed only within the context of an engine/thread. I ran into this a bit in ruby-i18n/i18n#625

The end-goal is to be able to say "within the context of this mounted engine (and threadsafe), these are the available locales." I18n doesn't currently allow that.

I'm currently debating with myself how much I want to propose that upstream in I18n, and how much I simply want to override Rails t/translate methods to get it working for us (or maybe both).

@bensheldon
Copy link
Owner

@Jay-Schneider fyi, I just released v3.15.1 which has the fix for setting a default via routes.

@Jay-Schneider
Copy link
Contributor Author

Hi @bensheldon sorry for not responding for a while. Thanks a lot for this quick and pragmatic solution! The locale select now works again as intended while the default locale is set to english by the definition in the routes.rb 👍

Regarding your explanation, I understand that the situation is more complicated than I first assumed.
Still, a GoodJob configuration option to set a default locale would be possible or am I missing something here? I suppose you would have to add a around_action to check whether an explicit locale is already selected and otherwise fall back to first config.good_job.default_locale and then I18n.default_locale 🤔
... which is a lot more manual intervention and less elegant than the current solution I guess.

So I wish you good luck finding a proper solution upstream 🙂 That sounds like the correct way to handle this.

Thanks again for your effort, the gem is awesome and you are doing a GoodJob! 😉

PS: Since there is now the possibility to do what I requested without larger drawbacks, feel free to close the issue or keep it open as a reminder that there is something to be done

@bensheldon
Copy link
Owner

I put together an I18n::Config monkeypatch that will allow setting a default_locale and disable enforce_available_locales in a thread-local way.

It's a little gross 🤷🏻 I tried to figure out how to do this with a narrower refinement, but couldn't come up with anything.

How it works:

This overrides those two methods to use a settable instance variable which is thread-local to the current thread's I18n.config instance, and then patches GoodJob's application controller to set and unset them.

# config/initializers/good_job_i18n_patch.rb
module GoodJobI18nPatch
  def default_locale
    @thread_default_locale.nil? ? super : @thread_default_locale
  end

  def thread_default_locale=(value)
    @thread_default_locale = value
  end

  def enforce_available_locales
    @thread_enforce_available_locales.nil? ? super : @thread_enforce_available_locales
  end

  def thread_enforce_available_locales=(value)
    @thread_enforce_available_locales = value
  end
end

I18n::Config.prepend(GoodJobI18nPatch)

ActiveSupport::Reloader.to_prepare do
  module GoodJob
    class ApplicationController
      prepend_around_action do |_controller, block|
        I18n.config.thread_default_locale = :en
        I18n.config.thread_enforce_available_locales = false
        block.call
      ensure
        I18n.config.thread_default_locale = nil
        I18n.config.thread_enforce_available_locales = nil
      end
    end
  end
end

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

No branches or pull requests

2 participants