I have ru.yml and en.yml files, the section I need looks like this:
en:
devise:
failure:
already_authenticated: You are already signed in.
ru:
devise:
failure:
already_authenticated: Вы уже вошли в систему.
The thing is, that no matter what language the user chooses, this (and several others) alert messages will be in russian.
My controllers have around_action :localize_request, which should determine the locale. And it works just fine for any other funcionality on the site, except for this particular case.
I think it could be a possible bug from devise. Take a look at this issue they discussed something similar and created a PR to fix it that I think is the reason why you can't translate your message.
As a workaround, maybe you can try to make this change to test if it works:
ru:
devise:
failure:
user: # <<<
already_authenticated: Вы уже вошли в систему.
Looks like it's a bug in the Devise gem -- https://github.com/heartcombo/devise/issues/5247
Related
I've a project that implements devise and I'm having trouble overriding the Passwords controller's messages.
When a wrong email address is entered by the user, Devise by default gives
Unable to find user with email {email}
I cant find the key to override this message in the devise.en.yml and can't find anything with the similar message on the devise repo as well.
Do I have an option other than to override the controller? Any help is appreciated.
Thanks
Add a new locale having the following structure:
en:
devise_token_auth:
passwords:
user_not_found: "Your custom message"
This message will be displayed when an invalid email is passed in the forgot password form.
Originally this message comes from the devise_token_auth gem. But if you have the same locale in your locale files, it will override the gem's locale.
It doesn't matter which *.en.yml file you will put this locale into. It can be devise.en.yml, or you can add a new file called devise_token_auth.en.yml. Only the structure matters.
as described in the following link you can generate the devise controller with
rails generate devise:controllers user
then you can over-ride the create or update action. If you include super in the new action, it will call the parent controller action and then execute the code.
You can also over-ride the devise messages as explained in this post, you just need to create that locale in your settings
en:
devise_token_auth:
sessions:
not_confirmed: "your message overwritten"
I am using Devise in a Rails 4 app. I am displaying a flash message after signin.
#app/controllers/application_controller.rb
def after_sign_in_path_for(resource_or_scope)
set_flash_message :alert, I18n.t( 'users.after_signin_msg')
end
I have a translation file
#config/locales/users.en.yml
en:
users:
after_signin_msg: "Hello and Welcome"
When a user signs in, the displayed flash message is
translation missing: en.devise.sessions.user.Hello and Welcome
Why is the Devise controller being displayed in the translation? And if Rails is looking under a Devise translation, why is the correct message being displayed as well?
How do I go about removing the translation missing text?
Came across this for another devise translation error and thought I would add the solution that worked for me.
ActionView::Template::Error (translation missing: en.devise.registrations.edit.back)
Solved it by changing t() -> I18n.t() for the single instance causing issues in the template.
Works, but not sure why it was necessary.
#ImranNaqvi suggested this in the comments:
#AndyHarvey you're right dear , little change i made was I18n.t instead of only t – ImranNaqvi Jul 23 '16 at 4:37
I'm having some problems with Rails I18n, more specifically with the keys in errors.messages.
The issue is that Rails itself define some translations (
https://github.com/svenfuchs/rails-i18n/blob/a7d33d1b319bdbaa1da64ced0aa0d280891a3a09/rails/locale/en.yml#L101 ). Example:
errors:
messages:
accepted: must be accepted
blank: can't be blank
present: must be blank
confirmation: doesn't match %{attribute}
empty: can't be empty
...
But Devise also defines some translations in errors.messages ( https://github.com/tigrish/devise-i18n/blob/ab598c6fdd8a029c9853fcf22788c27b828fae31/rails/locales/en.yml#L50 ). Example:
errors:
messages:
already_confirmed: was already confirmed, please try signing in
confirmation_period_expired: needs to be confirmed within %{period}, please request a new one
expired: has expired, please request a new one
not_found: not found
not_locked: was not locked
If Devise translation file is loaded before Rails translation file, it will be overwritten and vice-versa.
Is there a solution for this besides merging these keys manually in the same file?
You need not curb both the files together,
You can do the devise specific translations using the devise.es.yml in your config/locales folder. See here:
https://github.com/plataformatec/devise/wiki/I18n
while having your other messages in en.yml
Hope it helps!
I'm using the standard Rails I18n API to localise some of our views. This is working really well, but we now have a few use cases for regional changes to the en locale.
The API guide mentions that this isn't supported directly, and other plugins should be used. However, I'm wondering whether there's a simpler way to do this.
I already have en.yml, so in theory I could just create en-AU.yml and en-US.yml which are effectively clones of en.yml but with a few regional changes applied. I could then add additional English - American and English - Australian options to our configuration which would map to the new region-specific locales and allow users to use a region-specific locale.
The only problem I can think of with this is that it isn't DRY -- I would have duplicate translations for all common English words. I can't see a way around this.
Are there any other disadvantages to this approach, or should I just bite the bullet and dive into one of the plug-ins such as Globalize2 instead?
The rails-i18n-translation-inheritance-helper is getting a bit old now, so here's my approach for a Rails 3.2 project.
If you keep both en-US and en-AU in the same en.yml file you can use the yml repeated node to have a super en section:
For example:
en: &en
errors:
messages:
expired: "has expired, please request a new one"
not_found: "not found"
en-US:
<<: *en
en-AU:
<<: *en
errors:
messages:
not_found: "tis not found"
I'm using translation inheritance helper plugin for this.
In newer versions of Rails/i18n, they've added a fallback feature. Works similar to the outdated translation inheritance helper gem
see this answer for more info: Fall back to default language if translation missing
Trying to use my active record translations in config/locales/de.yml also in my views. I thought I am clever using this:
de:
activerecord:
attributes:
user:
login: "Benutzerkennung"
comment: "Bemerkungen"
And in my view this:
<%= label_tag :login, t('activerecord.attributes.user.login') %>
But instead of the translation value ("Benutzerkennung") I am getting the infamous
"translation missing: de, activerecord, attributes, user, login"
Has anybody got this working (not using the label translation plugin (I am wary of potential side effects), or User.humanize_attribute_name)? What am I missing? (it does work when I use "activerecord1" or something else than activerecord, so my setup seems to be fine)
Thanks!
Ok, my bad, it does work just fine. I fell in the YML formatting trap :(
To help you debug along the way, use "script/console" and the following statements:
- I18n.locale --> should output the locale you want to examine
- I18n.t('activerecord.attributes') --> should give you all the key/value pairs for your translation, if not, you made a formatting error in your YML file or it could not be found
And btw - the plugin works quite well http://github.com/iain/i18n_label/
if you don't like the result of ".human_name" (which the plugin uses), just fall back to I18n.t('your key')
Another method:
<%= label_tag :login, User.human_attribute_name(:login) %>
You should upgrade Rails gem to v2.3.11 (I tried to use 2.3.9, but now days it is not available so I suggest you 2.3.11)!
gem install -v=2.3.11 rails
You can find this issues documented here: Rails 2.3.9 Release notes