Devise uses the wrong locale for some flash messages #5247
Comments
|
cool, seems like im not the only one haha |
|
I think it's a pretty common issue unfortunately. See #3052 (comment) I think the best solution is to set the locale in a middleware rather than in the application controller, and also ensure that this middleware is loaded before warden, so it sets the locale before the warden middleware sets any flash messages. #4823 (comment) |
|
The Rails guides were updated to use It's safe to use: before_action :set_locale
def set_locale
I18n.locale = params[:locale] || I18n.default_locale
end |
|
I'm having this same problem. First I tried before_action :set_locale which seemed to work for a while, but then stopped working, I'm unsure why. Changing it to prepend_before_action :set_locale works for the time being, but I'm uncertain whether this is the final or correct way to solve the problem. The middleware is in my case not an issue, as the Locale middleware is not used. |
|
Update: it seems as if prepend_before_action is the correct solution. The actions without prepend are in this order: verify_signed_out_user , several of which are devise related, and will by default be executed before set_locale. |
|
@dssjoblom that's right, you need to make sure That said, the issue originally described here with |
|
@carlosantoniodasilva Do you have any suggestions other than using |
|
@sam-kim I have a WIP/possible fix here: https://github.com/heartcombo/devise/compare/ca-fix-i18n-locale-failure-app, haven't been able to wrap it up yet, but if you'd like to give it a shot let me know how it goes. Other than that, no ideas off the top of my head. |
|
Looks like that worked perfectly! Thank you for that and the quick response 😃 |
|
Cool, thanks for confirming. I'll try to wrap that up and push to master soon. |
|
@carlosantoniodasilva I tried the above fix. devise/lib/devise/failure_app.rb Line 105 in 45b831c devise/lib/devise/hooks/activatable.rb Line 10 in 45b831c |
|
Thanks @unosk! Definitely agree on the first one, I was actually thinking about wrapping the failure app with I'll have to check on the second one, but at a glance seems reasonable. 👍 |
|
Cross posting 70828da#commitcomment-46435559 for my future reference:
|
|
I am working on a new Rails app, I just installed This is my class ApplicationController < ActionController::Base
around_action :switch_locale
def switch_locale(&action)
locale = params[:locale] || I18n.default_locale
I18n.with_locale(locale, &action)
end
def default_url_options
{ locale: I18n.locale }
end
endThis is the class ApplicationController < ActionController::Base
before_action :switch_locale
def switch_locale
I18n.locale = params[:locale] || I18n.default_locale
end
def default_url_options
{ locale: I18n.locale }
end
endI am very new to i18n, but my current feelings are:
What should I do? What is the Rails/Ruby/Devise/i18n way to handle this? |
|
@pil0u using
You could try my branch: https://github.com/heartcombo/devise/compare/ca-fix-i18n-locale-failure-app (which I haven't been able to wrap up, but just updated it on top of current master), and see if that works for you while still using |
|
@carlosantoniodasilva just ran into this exact issue and I think your branch has the correct approach to solving this. Did you make any further progress, or perhaps found a better solution? |
|
I also had the same issue, and resulted in new rack middleware which handles query param, cookie and HTTP_ACCEPT_LANGUAGE header in this order, then store explicitly requested locale in cookie. ps. |
A common usage of I18n with different locales is to create some around callbcak in the application controller that sets the locale for the entire action, via params/url/user/etc., which ensure the locale is respected for the duration of that action, and resets at the end. Devise was not respecting the locale when the authenticate failed and triggered the failure app, because that happens in a warden middleware right up in the change, by that time the controller around callback had already reset the locale back to its default, and the failure app would just translate flash messages using the default locale. Now we are passing the current locale down to the failure app via warden options, and wrapping it with an around callback, which makes the failure app respect the set I18n locale by the controller at the time the authentication failure is triggered, working as expected. (much more like a normal controller would.) I chose to introduce a callback in the failure app so we could wrap the whole `respond` action processing rather than adding individual `locale` options to the `I18n.t` calls, because that should ensure other possible `I18n.t` calls from overridden failure apps would respect the set locale as well, and makes it more like one would implement in a controller. I don't recommend people using callbacks in their own failure apps though, as this is not going to be documented as a "feature" of failures apps, it's considered "internal" and could be refactored at any point. It is possible to override the locale with the new `i18n_locale` method, which simply defaults to the passed locale from the controller. Closes #5247 Closes #5246 Related to: #3052, #4823, and possible others already closed. Related to warden: (may be closed there afterwards) wardencommunity/warden#180 wardencommunity/warden#170
A common usage of I18n with different locales is to create some around callbcak in the application controller that sets the locale for the entire action, via params/url/user/etc., which ensure the locale is respected for the duration of that action, and resets at the end. Devise was not respecting the locale when the authenticate failed and triggered the failure app, because that happens in a warden middleware right up in the change, by that time the controller around callback had already reset the locale back to its default, and the failure app would just translate flash messages using the default locale. Now we are passing the current locale down to the failure app via warden options, and wrapping it with an around callback, which makes the failure app respect the set I18n locale by the controller at the time the authentication failure is triggered, working as expected. (much more like a normal controller would.) I chose to introduce a callback in the failure app so we could wrap the whole `respond` action processing rather than adding individual `locale` options to the `I18n.t` calls, because that should ensure other possible `I18n.t` calls from overridden failure apps would respect the set locale as well, and makes it more like one would implement in a controller. I don't recommend people using callbacks in their own failure apps though, as this is not going to be documented as a "feature" of failures apps, it's considered "internal" and could be refactored at any point. It is possible to override the locale with the new `i18n_locale` method, which simply defaults to the passed locale from the controller. Closes #5247 Closes #5246 Related to: #3052, #4823, and possible others already closed. Related to warden: (may be closed there afterwards) wardencommunity/warden#180 wardencommunity/warden#170
|
Hey all, I finally have a PR up with this change: #5567, if anyone wants to give it a shot, let me know if you run into any issues. |
A common usage of I18n with different locales is to create some around callbcak in the application controller that sets the locale for the entire action, via params/url/user/etc., which ensure the locale is respected for the duration of that action, and resets at the end. Devise was not respecting the locale when the authenticate failed and triggered the failure app, because that happens in a warden middleware right up in the change, by that time the controller around callback had already reset the locale back to its default, and the failure app would just translate flash messages using the default locale. Now we are passing the current locale down to the failure app via warden options, and wrapping it with an around callback, which makes the failure app respect the set I18n locale by the controller at the time the authentication failure is triggered, working as expected. (much more like a normal controller would.) I chose to introduce a callback in the failure app so we could wrap the whole `respond` action processing rather than adding individual `locale` options to the `I18n.t` calls, because that should ensure other possible `I18n.t` calls from overridden failure apps would respect the set locale as well, and makes it more like one would implement in a controller. I don't recommend people using callbacks in their own failure apps though, as this is not going to be documented as a "feature" of failures apps, it's considered "internal" and could be refactored at any point. It is possible to override the locale with the new `i18n_locale` method, which simply defaults to the passed locale from the controller. Closes #5247 Closes #5246 Related to: #3052, #4823, and possible others already closed. Related to warden: (may be closed there afterwards) wardencommunity/warden#180 wardencommunity/warden#170
A common usage of I18n with different locales is to create some around callbcak in the application controller that sets the locale for the entire action, via params/url/user/etc., which ensure the locale is respected for the duration of that action, and resets at the end. Devise was not respecting the locale when the authenticate failed and triggered the failure app, because that happens in a warden middleware right up in the change, by that time the controller around callback had already reset the locale back to its default, and the failure app would just translate flash messages using the default locale. Now we are passing the current locale down to the failure app via warden options, and wrapping it with an around callback, which makes the failure app respect the set I18n locale by the controller at the time the authentication failure is triggered, working as expected. (much more like a normal controller would.) I chose to introduce a callback in the failure app so we could wrap the whole `respond` action processing rather than adding individual `locale` options to the `I18n.t` calls, because that should ensure other possible `I18n.t` calls from overridden failure apps would respect the set locale as well, and makes it more like one would implement in a controller. I don't recommend people using callbacks in their own failure apps though, as this is not going to be documented as a "feature" of failures apps, it's considered "internal" and could be refactored at any point. It is possible to override the locale with the new `i18n_locale` method, which simply defaults to the passed locale from the controller. Closes #5247 Closes #5246 Related to: #3052, #4823, and possible others already closed. Related to warden: (may be closed there afterwards) wardencommunity/warden#180 wardencommunity/warden#170
A common usage of I18n with different locales is to create some around callbcak in the application controller that sets the locale for the entire action, via params/url/user/etc., which ensure the locale is respected for the duration of that action, and resets at the end. Devise was not respecting the locale when the authenticate failed and triggered the failure app, because that happens in a warden middleware right up in the change, by that time the controller around callback had already reset the locale back to its default, and the failure app would just translate flash messages using the default locale. Now we are passing the current locale down to the failure app via warden options, and wrapping it with an around callback, which makes the failure app respect the set I18n locale by the controller at the time the authentication failure is triggered, working as expected. (much more like a normal controller would.) I chose to introduce a callback in the failure app so we could wrap the whole `respond` action processing rather than adding individual `locale` options to the `I18n.t` calls, because that should ensure other possible `I18n.t` calls from overridden failure apps would respect the set locale as well, and makes it more like one would implement in a controller. I don't recommend people using callbacks in their own failure apps though, as this is not going to be documented as a "feature" of failures apps, it's considered "internal" and could be refactored at any point. It is possible to override the locale with the new `i18n_locale` method, which simply defaults to the passed locale from the controller. Closes #5247 Closes #5246 Related to: #3052, #4823, and possible others already closed. Related to warden: (may be closed there afterwards) wardencommunity/warden#180 wardencommunity/warden#170
|
The source of the problem, in my case, was located in the This issue arises because I addressed the problem by calling if authenticated && resource = warden.user(resource_name)
# Since 'require_no_authentication' uses 'prepend_before_action' while 'set_locale'
# uses 'before_action', the flash message may display with the incorrect locale.
# To fix this, ensure the locale is correctly set before displaying the flash message.
set_locale
set_flash_message! :alert, 'already_authenticated', scope: 'devise.failure' # This line was also tweaked a bit
redirect_to after_sign_in_path_for(resource)
endIt may not be the cleanest way to fix this, but it has the advantage of making very few modifications to the original codebase. EDIT: This is the exact same solution |
A common usage of I18n with different locales is to create some around callbcak in the application controller that sets the locale for the entire action, via params/url/user/etc., which ensure the locale is respected for the duration of that action, and resets at the end. Devise was not respecting the locale when the authenticate failed and triggered the failure app, because that happens in a warden middleware right up in the change, by that time the controller around callback had already reset the locale back to its default, and the failure app would just translate flash messages using the default locale. Now we are passing the current locale down to the failure app via warden options, and wrapping it with an around callback, which makes the failure app respect the set I18n locale by the controller at the time the authentication failure is triggered, working as expected. (much more like a normal controller would.) I chose to introduce a callback in the failure app so we could wrap the whole `respond` action processing rather than adding individual `locale` options to the `I18n.t` calls, because that should ensure other possible `I18n.t` calls from overridden failure apps would respect the set locale as well, and makes it more like one would implement in a controller. I don't recommend people using callbacks in their own failure apps though, as this is not going to be documented as a "feature" of failures apps, it's considered "internal" and could be refactored at any point. It is possible to override the locale with the new `i18n_locale` method, which simply defaults to the passed locale from the controller. Closes #5247 Closes #5246 Related to: #3052, #4823, and possible others already closed. Related to warden: (may be closed there afterwards) wardencommunity/warden#180 wardencommunity/warden#170
|
@FelixNumworks not sure there's much we can do over there, but if you use an Alternatively, setting the locale yourself and calling super like it was suggested in the issue might be fine too. I don't know if there's much else Devise can do since setting the locale is app specific. |
A common usage of I18n with different locales is to create some around callback in the application controller that sets the locale for the entire action, via params/url/user/etc., which ensure the locale is respected for the duration of that action, and resets at the end. Devise was not respecting the locale when the authenticate failed and triggered the failure app, because that happens in a warden middleware right up in the change, by that time the controller around callback had already reset the locale back to its default, and the failure app would just translate flash messages using the default locale. Now we are passing the current locale down to the failure app via warden options, and wrapping it with an around callback, which makes the failure app respect the set I18n locale by the controller at the time the authentication failure is triggered, working as expected. (much more like a normal controller would.) I chose to introduce a callback in the failure app so we could wrap the whole `respond` action processing rather than adding individual `locale` options to the `I18n.t` calls, because that should ensure other possible `I18n.t` calls from overridden failure apps would respect the set locale as well, and makes it more like one would implement in a controller. I don't recommend people using callbacks in their own failure apps though, as this is not going to be documented as a "feature" of failures apps, it's considered "internal" and could be refactored at any point. It is possible to override the locale with the new `i18n_locale` method, which simply defaults to the passed locale from the controller. Closes #5247 Closes #5246 Related to: #3052, #4823, and possible others already closed. Related to warden: (may be closed there afterwards) wardencommunity/warden#180 wardencommunity/warden#170
A common usage of I18n with different locales is to create some around callback in the application controller that sets the locale for the entire action, via params/url/user/etc., which ensure the locale is respected for the duration of that action, and resets at the end. Devise was not respecting the locale when the authenticate failed and triggered the failure app, because that happens in a warden middleware right up in the change, by that time the controller around callback had already reset the locale back to its default, and the failure app would just translate flash messages using the default locale. Now we are passing the current locale down to the failure app via warden options, and wrapping it with an around callback, which makes the failure app respect the set I18n locale by the controller at the time the authentication failure is triggered, working as expected. (much more like a normal controller would.) I chose to introduce a callback in the failure app so we could wrap the whole `respond` action processing rather than adding individual `locale` options to the `I18n.t` calls, because that should ensure other possible `I18n.t` calls from overridden failure apps would respect the set locale as well, and makes it more like one would implement in a controller. I don't recommend people using callbacks in their own failure apps though, as this is not going to be documented as a "feature" of failures apps, it's considered "internal" and could be refactored at any point. It is possible to override the locale with the new `i18n_locale` method, which simply defaults to the passed locale from the controller. Closes #5247 Closes #5246 Related to: #3052, #4823, and possible others already closed. Related to warden: (may be closed there afterwards) wardencommunity/warden#180 wardencommunity/warden#170
A common usage of I18n with different locales is to create some around callback in the application controller that sets the locale for the entire action, via params/url/user/etc., which ensure the locale is respected for the duration of that action, and resets at the end. Devise was not respecting the locale when the authenticate failed and triggered the failure app, because that happens in a warden middleware right up in the change, by that time the controller around callback had already reset the locale back to its default, and the failure app would just translate flash messages using the default locale. Now we are passing the current locale down to the failure app via warden options, and wrapping it with an around callback, which makes the failure app respect the set I18n locale by the controller at the time the authentication failure is triggered, working as expected. (much more like a normal controller would.) I chose to introduce a callback in the failure app so we could wrap the whole `respond` action processing rather than adding individual `locale` options to the `I18n.t` calls, because that should ensure other possible `I18n.t` calls from overridden failure apps would respect the set locale as well, and makes it more like one would implement in a controller. I don't recommend people using callbacks in their own failure apps though, as this is not going to be documented as a "feature" of failures apps, it's considered "internal" and could be refactored at any point. It is possible to override the locale with the new `i18n_locale` method, which simply defaults to the passed locale from the controller. Closes #5247 Closes #5246 Related to: #3052, #4823, and possible others already closed. Related to warden: (may be closed there afterwards) wardencommunity/warden#180 wardencommunity/warden#170
A common usage of I18n with different locales is to create some around callback in the application controller that sets the locale for the entire action, via params/url/user/etc., which ensure the locale is respected for the duration of that action, and resets at the end. Devise was not respecting the locale when the authenticate failed and triggered the failure app, because that happens in a warden middleware right up in the change, by that time the controller around callback had already reset the locale back to its default, and the failure app would just translate flash messages using the default locale. Now we are passing the current locale down to the failure app via warden options, and wrapping it with an around callback, which makes the failure app respect the set I18n locale by the controller at the time the authentication failure is triggered, working as expected. (much more like a normal controller would.) I chose to introduce a callback in the failure app so we could wrap the whole `respond` action processing rather than adding individual `locale` options to the `I18n.t` calls, because that should ensure other possible `I18n.t` calls from overridden failure apps would respect the set locale as well, and makes it more like one would implement in a controller. I don't recommend people using callbacks in their own failure apps though, as this is not going to be documented as a "feature" of failures apps, it's considered "internal" and could be refactored at any point. It is possible to override the locale with the new `i18n_locale` method, which simply defaults to the passed locale from the controller. Closes #5247 Closes #5246 Related to: #3052, #4823, and possible others already closed. Related to warden: (may be closed there afterwards) wardencommunity/warden#180 wardencommunity/warden#170
|
I've just upgraded from devise 4.7.3 to 4.9.4 and while this issue seems to be mostly resolved, I have noticed that the unconfirmed message still isn't localized for me. I've generated the new english locale file using rails g devise:install and am using a customized version of a German locale file from https://github.com/heartcombo/devise/wiki/I18n I'm on Ruby 2.7.8 / Rails 6.0 I'm using the around_action callback with I18n.with_locale(locale, &action) to set the locale in the application controller. |
Environment
Current behavior
Currently I use this code as suggested by the Rails guide:
This works perfectly for the application... but not for all Devise messages! Some are translated, others are not. Devise keeps using the default language for some messages (even if the translated YML files are present).
Possibly related:
#145
#5246
In order to reproduce the issue:
default_localeset in the environment files, not the current one set in application controller)If you log in successfully, instead, the flash message is in the correct language (the language set in application controller).
I have also tried to copy the official YML file from Devise and translate it, but I have the same issue: some translations appear, other do not.
Expected behavior
Devise should always use the current locale.
The text was updated successfully, but these errors were encountered: