-
-
Notifications
You must be signed in to change notification settings - Fork 204
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
Comments
@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 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 The end-goal is to be able to say "within the context of this mounted engine (and threadsafe), these are the available locales." I'm currently debating with myself how much I want to propose that upstream in |
@Jay-Schneider fyi, I just released |
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. 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 |
I put together an 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 # 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 |
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 thei18n.default_locale
if set.What do you think about that?
PS, for others with this concern: I experimented with a workaround using
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.The text was updated successfully, but these errors were encountered: