In rails 6.1.6.1 I have the following deprecation warning
DEPRECATION WARNING: action_view.raise_on_missing_translations is deprecated and will be removed in Rails 7.0. Set i18n.raise_on_missing_translations instead. Note that this new setting also affects how missing translations are handled in controllers.
How do I set the raise_on_missing_translations option, and where do I set it (e.g. in an initializer)?
Set config like this in application.rb or in specific environments:
config.i18n.raise_on_missing_translations = true
Related
I noticed in my rails 6 project that adding the following to config/initializers/rails_admin.rb results in a deprecation warning:
RailsAdmin.config do |config|
config.parent_controller = ApplicationController.to_s
# ...
Warning:
DEPRECATION WARNING: Initialization autoloaded the constants ApplicationHelper, AboutHelper, GroupHelper, MapHelper, DeviseHelper, ActionText::ContentHelper, and ActionText::TagHelper.
Being able to do this is deprecated. Autoloading during initialization is going
to be an error condition in future versions of Rails.
Reloading does not reboot the application, and therefore code executed during
initialization does not run again. So, if you reload ApplicationHelper, for example,
the expected changes won't be reflected in that stale Module object.
These autoloaded constants have been unloaded.
Please, check the "Autoloading and Reloading Constants" guide for solutions.
(called from <main> at /opt/app/config/environment.rb:5)
One workaround for this is to simply use "ApplicationController" instead of ApplicationController.to_s, but is there a way to do the latter approach without this deprecation warning?
yes, you are right
# Which class should be used for the controllers
config.parent_controller = '::ApplicationAdminController'
here the issue in the library issue_link
To which initializer file should I add the desired line of code?
I'm getting the following deprecation warning.
DEPRECATION WARNING: Time columns will become time zone aware in Rails 5.1. This still causes Strings to be parsed as if they were in Time.zone,
and Times to be converted to Time.zone.
To keep the old behavior, you must add the following to your initializer:
config.active_record.time_zone_aware_types = [:datetime]
To silence this deprecation warning, add the following:
config.active_record.time_zone_aware_types = [:datetime, :time]
I'm a rails newbie, I just want to follow best practice. Thanks!
add to config/application.rb inside class Application < Rails::Application this line:
config.active_record.time_zone_aware_types = [:datetime, :time]
create file /config/initializers/time_zone_aware_types.rb
then add next line to the file
Rails.application.config.active_record.time_zone_aware_types = [:datetime, :time]
I just updated to rails 4.0.2 and I'm getting this warning:
[deprecated] I18n.enforce_available_locales will default to true in the future. If you really want to skip validation of your locale you can set I18n.enforce_available_locales = false to avoid this message.
Is there any security issue in setting it to false?
Important: Make sure your app is not using I18n 0.6.8, it has a bug that prevents the configuration to be set correctly.
Short answer
In order to silence the warning edit the application.rb file and include the following line inside the Rails::Application body
config.i18n.enforce_available_locales = true
The possible values are:
false: if you
want to skip the locale validation
don't care about locales
true: if you
want the application to raise an error if an invalid locale is passed (or)
want to default to the new Rails behaviors (or)
care about locale validation
Note:
The old default behavior corresponds to false, not true.
If you are setting the config.i18n.default_locale configuration or other i18n settings, make sure to do it after setting the config.i18n.enforce_available_locales setting.
If your use third party gems that include I18n features, setting the variable through the Application config object, may not have an effect. In this case, set it directly to I18n using I18n.config.enforce_available_locales.
Caveats
Example
require File.expand_path('../boot', __FILE__)
# ...
module YouApplication
class Application < Rails::Application
# ...
config.i18n.enforce_available_locales = true
# or if one of your gem compete for pre-loading, use
I18n.config.enforce_available_locales = true
# ...
end
end
Long answer
The deprecation warning is now displayed both in Rails 4 (>= 4.0.2) and Rails 3.2 (>= 3.2.14). The reason is explained in this commit.
Enforce available locales
When I18n.config.enforce_available_locales is true we'll raise an
I18n::InvalidLocale exception if the passed locale is unavailable.
The default is set to nil which will display a deprecation error.
If set to false we'll skip enforcing available locales altogether (old behaviour).
This has been implemented in the following methods :
I18n.config.default_locale=
I18n.config.locale=
I18n.translate
I18n.localize
I18n.transliterate
Before this change, if you passed an unsupported locale, Rails would silently switch to it if the locale is valid (i.e. if there is a corresponding locale file in the /config/locales folder), otherwise the locale would default to the config.i18n.default_locale configuration (which defaults to :en).
The new version of the I18n gem, forces developers to be a little bit more conscious of the locale management.
In the future, the behavior will change and if a locale is invalid, the Rails app will raise an error.
In preparation of such change (that may potentially break several applications that until today were relying on silent defaults), the warning is forcing you to explicitly declare which validation you want to perform, during the current transition period.
To restore the previous behavior, simply set the following configuration to false
config.i18n.enforce_available_locales = false
otherwise, set it to true to match the new Rails defaults or if you want to be more rigid on domain validation and avoid switching to the default in case of invalid locale.
config.i18n.enforce_available_locales = true
Caveat
If you are setting the config.i18n.default_locale configuration or using any of the previously mentioned methods (default_locale=, locale=, translate, etc), make sure to do it after setting the config.i18n.enforce_available_locales setting. Otherwise, the deprecation warning will keep on popping up. (Thanks Fábio Batista).
If you use third party gems that include I18n features, setting the variable through may not have effect. In fact, the issue is the same as described in the previous point, just a little bit harder to debug.
This issue is a matter of precedence. When you set the config in your Rails app, the value is not immediately assigned to the I18n gem. Rails stores each config in an internal object, loads the dependencies (Railties and third party gems) and then it passes the configuration to the target classes. If you use a gem (or Rails plugin) that calls any of the I18n methods before the config is assigned to I18n, then you'll get the warning.
In this case, you need to skip the Rails stack and set the config immediately to the I18n gem by calling
I18n.config.enforce_available_locales = true
instead of
config.i18n.enforce_available_locales = true
The issue is easy to prove. Try to generate a new empty Rails app and you will see that setting config.i18n in the application.rb works fine.
If in your app it does not, there is an easy way to debug the culprit. Locate the i18n gem in your system, open the i18n.rb file and edit the method enforce_available_locales! to include the statement puts caller.inspect.
This will cause the method to print the stacktrace whenever invoked. You will be able to determine which gem is calling it by inspecting the stacktrace (in my case it was Authlogic).
["/Users/weppos/.rvm/gems/ruby-2.0.0-p247#application/gems/i18n-0.6.9/lib/i18n.rb:150:in `translate'",
"/Users/weppos/.rvm/gems/ruby-2.0.0-p247#application/gems/authlogic-3.1.0/lib/authlogic/i18n/translator.rb:8:in `translate'",
"/Users/weppos/.rvm/gems/ruby-2.0.0-p247#application/gems/authlogic-3.1.0/lib/authlogic/i18n.rb:79:in `translate'",
"/Users/weppos/.rvm/gems/ruby-2.0.0-p247#application/gems/authlogic-3.1.0/lib/authlogic/acts_as_authentic/email.rb:68:in `validates_format_of_email_field_options'",
"/Users/weppos/.rvm/gems/ruby-2.0.0-p247#application/gems/authlogic-3.1.0/lib/authlogic/acts_as_authentic/email.rb:102:in `block in included'",
"/Users/weppos/.rvm/gems/ruby-2.0.0-p247#application/gems/authlogic-3.1.0/lib/authlogic/acts_as_authentic/email.rb:99:in `class_eval'",
"/Users/weppos/.rvm/gems/ruby-2.0.0-p247#application/gems/authlogic-3.1.0/lib/authlogic/acts_as_authentic/email.rb:99:in `included'",
"/Users/weppos/.rvm/gems/ruby-2.0.0-p247#application/gems/authlogic-3.1.0/lib/authlogic/acts_as_authentic/base.rb:37:in `include'",
"/Users/weppos/.rvm/gems/ruby-2.0.0-p247#application/gems/authlogic-3.1.0/lib/authlogic/acts_as_authentic/base.rb:37:in `block in acts_as_authentic'",
"/Users/weppos/.rvm/gems/ruby-2.0.0-p247#application/gems/authlogic-3.1.0/lib/authlogic/acts_as_authentic/base.rb:37:in `each'",
"/Users/weppos/.rvm/gems/ruby-2.0.0-p247#application/gems/authlogic-3.1.0/lib/authlogic/acts_as_authentic/base.rb:37:in `acts_as_authentic'",
"/Users/weppos/Projects/application/app/models/user.rb:8:in `<class:User>'",
"/Users/weppos/Projects/application/app/models/user.rb:1:in `<top (required)>'",
Just for completeness, note that you can also get rid of the warning by setting I18n.enforce_available_locales to true (or false) in config/application.rb:
require File.expand_path('../boot', __FILE__)
.
.
.
module SampleApp
class Application < Rails::Application
.
.
.
I18n.enforce_available_locales = true
.
.
.
end
end
I18n.config.enforce_available_locales = true worked for me in Rails 3.2.16 (I put it in config/application.rb)
Doesn't seem that way - that'd be previous behavior of the way i18n works - new behavior (true) will raise an error when you ask for a locale not implemented/available.
See the commit that added this warning: https://github.com/svenfuchs/i18n/commit/3b6e56e06fd70f6e4507996b017238505e66608c
If you want to care about locales write into appilcation.rb file.
config.i18n.enforce_available_locales = true
You can write false if locale validation and do not care about that.
I've just updated to Rails 4.0.2 and I got the deprecation warning:
[deprecated] I18n.enforce_available_locales will default to true in the future. If you really want to skip validation of your locale you can set I18n.enforce_available_locales = false to avoid this message.
To get rid of the warning, I decided to set:
I18n.config.enforce_available_locales = true
in my config/application.rb file.
It worked pretty well on Development, all tests passed, and I was happy... Then I deployed my work in a staging server and it crashed!
Devise is looking for a locale :pt. All I have is a locale :pt-BR. I set it in my application.rb:
config.i18n.default_locale = 'pt-BR'
I don't know why devise is looking for :pt only. My locales in the config folder are: pt-BR.yml and devise.pt-BR.yml.
I tried to change the file name from devise.pt-BR.yml to devise.pt.yml (and inside from pt-BR to pt) and it worked.
I had to go back and set:
I18n.config.enforce_available_locales = false
to make it work.
I have two questions:
1 - Why this is not happening on the tests and on development?
2 - Why Devise is asking for :pt, if I'm setting the default locale as :pt-BR in my config?
Thanks in advance
Add devise-i18n to your Gemfile to get the pt-BR locale file for the Devise strings. This fixes the production problem.
As for why you're not seeing the issue in development, it may be because you're not triggering the specific I18n.t lookup - you need to narrow it down. Some Devise string is triggering this, and I suspect it won't cause an error until that string gets looked up. You need to narrow down the exact set of actions that causes the issue. If it's failing on startup, there might be some production eager loading going on that triggers the issue.
Can anyone tell me how to silence deprecation warinings in Rails 3?
I have a few situations where it is throwing false positives. Namely using - for loops in haml and f.error_messages from the dynamic_form plugin.
Thanks
To silence all deprecation warnings you can do:
ActiveSupport::Deprecation.silenced = true
This could be placed in an initializer or in the environment file for a specific environment (e.g. to silence only in production for example.)
Or for a specific section of code, enclose it in a block:
ActiveSupport::Deprecation.silence do
# no warnings for any use of deprecated methods here
end
This works for both Rails 3 & 4.
The accepted answer didn't work for me with Rails 3.2.12. Placing it in either the environments/production.rb or an initializer still outputted the warnings. I had to put it in my config/environment.rb file before the application was initialized:
# Load the rails application
require File.expand_path('../application', __FILE__)
::ActiveSupport::Deprecation.silenced = true if Rails.env.production?
# Initialize the rails application
Notices::Application.initialize!
Ryan Daigle wrote an article about this, in which he also showed how you can intercept the deprecation warning and do something else with it, like send it to a log file:
ActiveSupport::Deprecation.behavior = Proc.new { |msg, stack| MyLogger.warn(msg) }
http://ryandaigle.com/articles/2006/12/4/how-to-turn-deprecation-warnings-off-in-rails