devise-in18n messages not localized

I have deployed devise & devise-i18n to internationalize devise. Everything works well - including all the i18n - except that flash messages generated by devise do not get translated

=> messages generated by devise and accessed via resource.errors.full_messages are localized
e.g. try to “sign_up” with no information filled in

=> flashes generated by devise are not localized
e.g. try to “sign_in” with no information filled in

Any idea why? Any idea on how to fix this?

Have you created settings for i18n in application.rb ?

Here’s what application.rb looks like on one of my sites that uses locales:

Rails.application.config.i18n.available_locales = [“ko”, “zh-TW”, “ja”, “en-US”]
Rails.application.config.i18n.default_locale = “en-US”
ISO3166.configure do |config|
config.locales = [‘zh-TW’, ‘en-US’, ‘ko’, ‘ja’]

Sure, my application.rb contains the following:

config\.i18n\.available\_locales = \[:en, :fr\]
config\.i18n\.default\_locale = :en
config\.i18n\.fallbacks = \[I18n\.default\_locale\]

The last line of your application.rb comes from heroes Gem, which I do not use.

On your website, are you sure the flash messages are localised? And if yes, which version of the devise and devise-i18n are you using?

Thanks

Cedric

From the code you can see it uses internationalization
https://github.com/plataformatec/devise/blob/098345aace53d4ddf88e04f1eb2680e2676e8c28/app/controllers/devise_controller.rb#L182

You can do something like this on an initializer so override the I18n
lookup method to print each key it tries to find, maybe you can
debug what's going on:

# config/initializers/debug_18n.rb

module I18n
module Backend
class Simple
# Monkey-patch-in localization debugging
# Enable with ENV['I18N_DEBUG']=1 on the command line in server startup, or
./config/environments/*.rb file.

Thank you very much for your message. I discovered actually that someone had developed an i18n debug Gem that is very helpful to troubleshoot this.

I discovered actually that some keys where missing and that for some reason i18n was first relying on the fallback locale instead of looking in the translation file.
Filling in the missing locale entries allowed me to fix this.

Cedric