-
Notifications
You must be signed in to change notification settings - Fork 162
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
I18n::InvalidLocale "en" is not a valid locale #544
Comments
Same thing happens when I add it as a class instead of a command 'DailyInstagramPost':
class: InstagramPostJob
schedule: "at 12pm every day"
|
Hmm, i 'fixed' it with: class MyRecurringCommandJob < ApplicationJob
I18n.locale = I18n.default_locale
def perform(command)
eval(command) # rubocop:disable Security/Eval
end
end though I still think this is a bug that should looked into.. |
Hey @martijnenco, yeah, I'll look into it. I'm surprised this hasn't come up before, as I know many people using Solid Queue with not the default locales based on some fixes I had to do in Mission Control – Jobs. I'll try to figure out what it is. |
@rosa Thanks a bunch! I dont know if it's relevant but I also have issues inside mission control, there the locale is also forceset on 'en'. And most translations/date-locals are missing. |
@martijnenco, Mission Control uses only I've been looking into this but I don't know what's going on. The locale management in jobs is all done by Active Job. It uses the value set by |
@rosa It's already a huge consolation for me that you aren't able to figure it out aswell. The mission control issue for me is this: (this is development, where I18n::MissingTranslationData in MissionControl::Jobs::Jobs#index
Showing /home/martijn/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/mission_control-jobs-1.0.2/app/views/mission_control/jobs/jobs/_job.html.erb where line #9 raised:
Translation missing: en.datetime.distance_in_words.x_days
Extracted source (around line #90):
I18n.exception_handler = ->(exception, *) {
exception = exception.to_exception if exception.is_a?(I18n::MissingTranslation)
raise exception
}
end
end This leads me to this: where locale is set set to I did now figure out that at the moment the callstack the gem sentry-rails hits, the Anway, the app is deployed and started with the use of No where in my application I define additional languages. I do have some gems that may (but unlikely) cause side-effects: # I18n
gem 'currencies'
gem 'http_accept_language', '~> 2.1'
gem 'route_translator', '~> 14.1'
gem 'tzinfo-data', platforms: %i[mingw mswin x64_mingw jruby] |
In theory this should just work as well... I'm going to try to reproduce this with a very simple app. |
Hey @martijnenco, I haven't managed to reproduce this 😕 I've created a brand new app with all defaults, and then made the following changes: diff --git a/config/application.rb b/config/application.rb
index fc3289e..e43d7fc 100644
--- a/config/application.rb
+++ b/config/application.rb
@@ -23,5 +23,7 @@ class Application < Rails::Application
#
# config.time_zone = "Central Time (US & Canada)"
# config.eager_load_paths << Rails.root.join("extras")
+ config.i18n.default_locale = "nl-NL"
+ config.i18n.available_locales = [ "nl-NL", "en-GB" ]
diff --git a/config/database.yml b/config/database.yml
index 2640cb5..e1e6f3a 100644
--- a/config/database.yml
+++ b/config/database.yml
@@ -10,8 +10,13 @@ default: &default
timeout: 5000
development:
- <<: *default
- database: storage/development.sqlite3
+ primary:
+ <<: *default
+ database: storage/development.sqlite3
+ queue:
+ <<: *default
+ database: storage/development_queue.sqlite3
+ migrations_paths: db/queue_migrate
# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
diff --git a/config/environments/development.rb b/config/environments/development.rb
index 4cc21c4..089f6ff 100644
--- a/config/environments/development.rb
+++ b/config/environments/development.rb
@@ -69,4 +69,8 @@
# Apply autocorrection by RuboCop to files generated by `bin/rails generate`.
# config.generators.apply_rubocop_autocorrect_after_generate!
+
+ # Replace the default in-process and non-durable queuing backend for Active Job.
+ config.active_job.queue_adapter = :solid_queue
+ config.solid_queue.connects_to = { database: { writing: :queue } }
diff --git a/config/puma.rb b/config/puma.rb
index a248513..8f393c3 100644
--- a/config/puma.rb
+++ b/config/puma.rb
@@ -34,7 +34,7 @@
plugin :tmp_restart
# Run the Solid Queue supervisor inside of Puma for single-server deployments
-plugin :solid_queue if ENV["SOLID_QUEUE_IN_PUMA"]
+plugin :solid_queue Then, I've added the following to test_locale_job:
class: TestLocaleJob
schedule: every second And created this job: class TestLocaleJob < ApplicationJob
def perform
Rails.logger.warn("Running TestLocaleJob with I18n.locale = #{I18n.locale}")
end
end Then, when starting Rails, everything works as expected:
Jobs are correctly enqueued with the default locale. From the rails console:
|
Hmm, let me try to reproduce this aswell.. |
@martijnenco, yes, I used Rails 8. I saw you were using Rails 7.2, but I don't think the code involved has changed in a way that would make this break 🤔 I might be wrong, though! |
@rosa Hmmpf, I also can't reproduce it in a new app (running rails 7.2.2) :/ Really curious what it could be.. Anyway, if anyone has the same bug, this is a workaround: Rails.application.config.after_initialize do # or to_prepare
SolidQueue::RecurringTask.default_job_class = MyRecurringCommandJob
end
class MyRecurringCommandJob < ApplicationJob
I18n.locale = I18n.default_locale
def perform(command)
eval(command) # rubocop:disable Security/Eval
end
end |
Problem: I am trying to have recuring jobs, and I have them configured like this:
Valid locals are configured in my application.rb:
Results in the current error as seen in mission control:
with Raw data where we indeed see the wrong locale, but where it comes from..
Versions:
solid_queue (1.1.4)
mission_control-jobs (1.0.2)
rails (7.2.2.1)
ruby 3.2.2p53
Please help :) I'm a bit lost on where it thinks is should be
"locale": "en",
..The text was updated successfully, but these errors were encountered: