Could you app Bulgarian (bg) to the locale app project, so that I can translate it. Thank you.

Thanks you for this awesome gem.
I'm using master branch (gem 'devise-i18n', github: 'tigrish/devise-i18n', branch: 'master'). Unfortunately rails still renders (old) devise views like:

Processing by Devise::SessionsController#new as HTML
  Rendered /home/lukas/.rvm/gems/ruby-2.3.0/gems/devise-3.5.6/app/views/devise/shared/_links.html.erb (27.6ms)
  Rendered /home/lukas/.rvm/gems/ruby-2.3.0/gems/devise-3.5.6/app/views/devise/sessions/new.html.erb within layouts/application (692.6ms)
Completed 200 OK in 981ms (Views: 944.8ms | ActiveRecord: 3.6ms)

When I generate views to my project by rails g devise:views:i18n_templates then everyting is OK.

The problem is that devise-i18n views are not included in the view paths. (At first I was suspicious that there is a wrong order in view paths array, I temporarily move default devise view away (mv /home/lukas/.rvm/gems/ruby-2.3.0/gems/devise-3.5.6/app/views/devise/sessions/new.html.erb{,.bak}) doesn't help).

A security issue has been induced by a German translation: https://www.localeapp.com/projects/377/translations/2034179?in_locale=1648

Source of the problem:

devise.failure.invalid:  %{authentication_keys} oder Passwort ungültig.
devise.failure.not_found_in_database: %{authentication_keys}-Adresse oder Passwort ungültig. 

As those two translations are not exactly the same, it is possible to differentiate if, during login failure, an user exists in the database or not. This is actually a security treat, as if no locking mechanism has been setup, it is possible to check the existence of an user and then guess the password.

Translation updated in: https://www.localeapp.com/projects/377/translations/2034179?in_locale=1648

devise-i18n (1.0.1)

Devise doesn't produce localized link in confirmation email.

It has to be:

http://localhost:3000/sk/users/confirmation?confirmation_token=...

and is:

http://localhost:3000/users/confirmation?confirmation_token=...

routes.rb

Rails.application.routes.draw do
  scope "(:locale)", locale: /#{I18n.available_locales.join('|')}/ do
    root to: 'visitors#index'
    devise_for :users
    resources :users
    get "/pages/:id" => "high_voltage/pages#show", :as => :page, :format => false
  end
end

For the German translation, it would be great to have two variants: a formal ("Sie", current) and additional an informal variant ("Du").

Those two variants currently exist (as gists) at https://github.com/plataformatec/devise/wiki/I18n#german-devisedeyml

If you think this is a good idea, I can help you migrating the data for the informal variant.

Devise complaining about some deprecated locale entries

[DEVISE] devise.registrations.inactive_signed_up in yml files is deprecated, please use devise.registrations.signed_up_but_REASON instead. The default values are:

en:
  devise:
    registrations:
      signed_up_but_unconfirmed: 'A message with a confirmation link has been sent to your email address. Please open the link to activate your account.'
      signed_up_but_inactive: 'You have signed up successfully. However, we could not sign you in because your account is not yet activated.'
      signed_up_but_locked: 'You have signed up successfully. However, we could not sign you in because your account is locked.'

I currently have a branch for fix complaining in hungarian translation, but it would be great if it is merged into other languages. However, you do not mention them in the gem, and I do not know how I can notify them about this change.

heartcombo/devise@6260c29#diff-d2a57dc1d883fd21fb9951699df71cc7

<%= f.submit t('.sign_up', :default => "Sign up"), :class => "com-next-bgcolor reg-btn"%>
Not work.
I have to change like this manual?
<%= f.submit t('devise.registrations.new.sign_up', :default => "Sign up"), :class => "com-next-bgcolor reg-btn"%>

Please add the new strings!
I can't do this via the Locate app at my own.

Have a look at e.g. the Czech translation (it's for Devise 2.2.2 yet)
https://github.com/plataformatec/devise/wiki/I18n (direct gist)

Thanks,
Flo

I think it should do the same thing rais-i18n does. Load only locales in i18n.available_locales if set, load every locale otherwise.

Is there's a reason to load everything?

Devise introduced some new strings that aren't in the localeapp. Please, update!

Devise::VERSION.start_with?('3.') ? @token : @resource.reset_password_token

This is not accurate as Devise 4 use @token as well.

No idea if you get notified with localeapp, but I've translated "email" to "courriel", which is the correct word in french.

http://french.about.com/b/2003/07/12/courriel-cest-officiel.htm

I'm currently a maintainer of devise-i18n-views gem. I would like to propose that the functionality of that gem be merged into devise-i18n. I've read the comment in #13, but I'd like to present my case.

The purpose of any gem (or software in general) is to be useful to users. The purpose of both devise-i18n and devise-i18n-views is to provide i18n for devise. The fact that some of this i18n is done simply with locale files and some requires views included isn't of much consequence to the gem users. In fact, having them separate causes confusion for users and requires both projects to tell people to use the other.

The same confusion arises for contributors to the gems (mcasimir/devise-i18n-views#68 #92). These contributors will also either only contribute to one project, or need to keep track of two separate projects. Having them as one will mean an easier job for contributors and likely more complete translations.

Finally, having one project will make it easier for me and you (the maintainer of this gem). Having additional people to look at pull requests or sync from localeapp will make us more responsive.

Devise Views gem had this:

    passwords:
      expired:
        renew_your_password: Renew your password
        change_required: Your password is expired. Please change your password.
        change_required_days: Your password is older than %{days} days. Please change your password.

Any chance we can add this back to this gem?

It is possible to use this gem inside another rails engine gem as a dependency? Simply adding it as a dependency inside the gemspec file does not work. But adding it to the main rails gemfile works.

Thanks.

I am getting this error for every yml file in the gem.

Errno::EACCES: Permission denied - /usr/local/lib/ruby/gems/1.9.1/gems/devise-i18n-0.5.1/locales/vi.yml

When I chmod the files to 0644 then everything works.

From the source code, in locales/zh-TW.yml, the entry "not_found_in_database" is empty. Reference the zh-CN.yml, this value should be the same as that for entry "invalid".

This will cause translation error when the user tries to login without his/her user account registered.

Thanks,
MetaSync

Hello,

is it possible to add a generator or something like this to the devise-18n gem that generates or overrides the normal devise views with some that are internationalized?

Another user has internationalized the views, but devise does not want them inside the 'normal' gem: heartcombo/devise#1699

I really would like to do the integration, but I don't know how?! I any one could give me some hint I really would like to try.

Hi,

I've made a fork and I am adding the romanian translation

Hi,

We added a new locale including translations at Localeapp, and we would like to release a new software version soon. Additionally, we use https://github.com/mcasimir/devise-i18n-views (which is migrated into this repo, according to the https://github.com/tigrish/devise-i18n/blob/master/CHANGELOG.md). Would it be possible to update the locales from Localeapp, and release a new version of devise-i18n? Can we help?

Cheers,
Lukas

For instance, .rvmrc

Hey, one of our translators taking care of the Czech translation noticed that a better translation of "Sign in" would be "Přihlásit se". I think of this line specifically (but this may apply to other places as well):

Some examples of popular websites using this wording below:

• Google

• Facebook

• Airbnb

Does anyone being responsible for the Czech translation of Devise have an opinion on this? =)

devise-i18n (1.0.1)

Started GET "/en/users" for 127.0.0.1 at 2016-04-06 21:28:15 +0200
Processing by UsersController#index as HTML
  Parameters: {"locale"=>"en"}
Completed 401 Unauthorized in 1ms (ActiveRecord: 0.0ms)


Started GET "/users/sign_in" for 127.0.0.1 at 2016-04-06 21:28:15 +0200
Processing by Devise::SessionsController#new as HTML
  Rendered devise/sessions/new.html.erb within layouts/application (4.6ms)
  Rendered layouts/_navigation_links.html.erb (0.4ms)
  Rendered layouts/_nav_links_for_auth.html.erb (1.0ms)
  Rendered layouts/_navigation.html.erb (3.8ms)
  Rendered layouts/_messages.html.erb (0.2ms)
Completed 200 OK in 124ms (Views: 122.7ms | ActiveRecord: 0.0ms)

default locale is set to "sk" and here is the result:

routes.rb

Rails.application.routes.draw do
  scope "(:locale)", locale: /#{I18n.available_locales.join('|')}/ do
    root to: 'visitors#index'
    devise_for :users
    resources :users
    get "/pages/:id" => "high_voltage/pages#show", :as => :page, :format => false
  end
end

part of application.rb

    config.i18n.available_locales = [:en, :sk]
    # config.i18n.load_path += Dir[Rails.root.join('my', 'locales', '*.{rb,yml}').to_s]
    config.i18n.default_locale = :sk

I want to have a 'Log out' or 'Sign out' button, but I cannot find the translation key for it.

Does it not exist?

Should it not exist here under sessions:
https://github.com/tigrish/devise-i18n/blob/master/rails/locales/en.yml#L106

Are view localisation keys out of scope for this project?

example:

registrations:
      edit:
        edit: "Edit"
        email: "Email"
        password: "Password"
        password_confirmation: "Password confirmation"
        current_password: "Current password"
        cancel_my_account: "Cancel my account"
        update: "Update"
        back: "Back"
        are_you_sure: "Are you sure?"
        unhappy: "Unhappy?"
        we_need_password_to_confirm: "(we need your current password to confirm your changes)"
        leave_blank_if_no_change: "(leave blank if you don't want to change it)"
      new:
        sign_up: "Sign up"
        email: "Email"
        password: 'Password'
        password_confirmation: "Password confirmation"

Generator command doesn't work with last published release (1.0.1).
I had to specifiy master branch on my gemfile to be able to use the generator command:

gem 'devise-i18n', github: 'tigrish/devise-i18n', branch: 'master'

Devise v. 4.0.0 isn't working along with devise-i18n.

I have submitted a PR.

With the current blank translations I can't show invalid messages for my users who fail to login.

invalid and not_fonud_in_database translations were removed with #114, but now Devise is settled on using Invalid %{authentication_keys} or password. for en, should we update all languages to this format?

zh-TW for example:

invalid: "%{authentication_keys}或密碼是無效的。"
not_found_in_database: "%{authentication_keys}或密碼是無效的。"

Hi I am translating device messages to my native language but CI is failing at this point.

rspec ./spec/locale_files_spec.rb[44:2] # a devise-i18n rails/locales/ur.yml locale file should be a subset of "rails/locales/en.yml"

Hi, there

I have an error when use devise-i18n 1.6.3 version.

I have two versions of devise-i18n gems (1.6.3, 1.6.2)
So, I tried to change gem version 1.6.2

gem 'devise-i18n', '1.6.2'

After change and deploy my eb environment, I can fix problem.

Can we update dependencies in Gemfile to depend on Bundler 1.1? My tests says the new version is OK.

Another question is about archaic RSpec version. Is there any reason why we do not update RSpec to the latest 2.8 version? I didn't do any test against it, but if it is needed, I can do it.

Rationale

I used rails g devise:i18n:views user to create scoped views for my User model, since I will have multiple Devise models (see Devise documentation). This did create the views in app/views/users as expected.
I also used rails g devise:i18n:locale es-MX to generate the locale file, and it was generated as expected.

Problem

Since the views are scoped, I had to do the following:

# devise.views.es-MX.yml
devise: &devise_views
  confirmations:
  # ....
users:
    <<: *devise_views

in order for the app to properly find the translations.

I can also see errors like translation missing: es-MX.devise.failure.user.not_found_in_database , which, again, could be solved with the following:

# devise.views.es-MX.yml
failure:
      user: &failure_user
        already_authenticated: Ya has iniciado sesión.
        # ...
      <<: *failure_user

Question

Is there an "official" way to accomplish what I need (i.e. generating locale files that work for scoped views), or can I get a full list of where in the locale file do I need to patch as previously mentioned?

There are some new strings in the original locale file of devise 2.1.2

https://github.com/plataformatec/devise/tree/v2.1.2/config/locales

how come there is no string for a sign out link?

The i18n files seem to be different from the last stable version:

https://github.com/plataformatec/devise/blob/v3.1/config/locales/en.yml

When I try to run the spec file in my translated version I get an error:

Failures:

  1) a devise-i18n locales/pt.yml locale file 
     Failure/Error: it { locale_file.should be_a_subset_of 'locales/en.yml' }
       expected locales/pt.yml to not include :
       - devise.confirmations.confirmed_and_signed_in
     # ./spec/devise-i18n_spec.rb:6:in `block (3 levels) in <top (required)>'

The current zh-HK file is not written in Mandarin (cmn, often assumed for zh "Chinese"), but in Cantonese (yue), causing a mismatch in language tagging and user expectation when they select zh-HK -- Hong Kongese Chinese, or Mandarin written in Traditional characters with Hong Kong terminology. It would be great if someone can check whether 639-2 codes are supported and move zh-HK to something like yue-HK if there is some support.

I'm probably doing something wrong here, but i have set default locale (application.rb => config.i18n.default_locale = :el) and i have the gem, but i don't get the devise.el.yml file and thus i get error messages from the flash messages and such.

For the record, these are my gems that i use for bootstrap views, devise and rails i18n:
gem 'devise-bootstrap-views'
gem 'rails-i18n', '~> 4.0.0'
gem 'devise-i18n'
gem 'devise-i18n-views'

for the time being i copy-pasted the data but i would like to know.

Hi,

Trying a bundle update I get::

"Ruby 1.9 is not supported. Please switch to simplecov"

Updating the gem file to "simplecov" does the trick, is that desirable?

Regards,

I noticed that for both en.yml and en-GB.yml that the text for devise.failure.invalid and devise.failure.not_found_in_database do not match which I think is inconsistent. Also, the Devise version of this string includes a placeholder for the type of key:

"Invalid %{authentication_keys} or password."

I think it would be better to have en and en-GB translations updated to use the same text and if possible also use the place holder.

Thanks,
Andrew

when having simple form in the gemfile the generators file with the below message.
without the simple form gem in the gemfile the generation of the templates is working fine.

Running via Spring preloader in process 34125
      invoke  Devise::I18n::SharedViewsGenerator
       exist    app/views/devise/shared
   identical    app/views/devise/shared/_links.html.erb
      invoke  Devise::I18n::MailerViewsGenerator
       exist    app/views/devise/mailer
   identical    app/views/devise/mailer/confirmation_instructions.html.erb
   identical    app/views/devise/mailer/password_change.html.erb
   identical    app/views/devise/mailer/reset_password_instructions.html.erb
   identical    app/views/devise/mailer/unlock_instructions.html.erb
      invoke  i18n:simple_form_for
Could not find "confirmations" in any of your source paths. Your current source paths are:
/Users/xxx/yyy/lib/templates/devise/simple_form_for
/Users/xxx/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/devise-i18n-1.1.0/lib/generators/devise/templates/simple_form_for

Encoding::CompatibilityError in Admin::DashboardController#index

incompatible character encodings: UTF-8 and ASCII-8BIT

translation data {:one=>"une erreur a empêché ce (ou cette) %{resource} d’être enregistré(e) :",
:other=>"%{count} erreurs ont empêché ce (ou cette) %{resource} d’être enregistré(e) :"} 
can not be used with :count => 3

I've had several French Pluralization errors even with other components, I think it's a problem of using :other instead of :many, or something similar.

Hi, Norwegian and Ukrainian translations were added at Locale. Please merge them to repo 😄

I presented a case to have localized views in devise core, but it was (fairly) rejected. Please see:
heartcombo/devise#1658
Perhaps we could implement localized views in devise-i18n? I honestly don't see why someone would use devise-i18n and not want localized views, but perhaps I'm wrong? If it is not preferable to add the views in devise-i18n I'll end up making my own extension to do this but I worry about needless fragmentation. I think it would be nice to have a drop-in solution for fully localized devise.

I recently found that the locale code for Vietnam used in the gem 'devise-i18n' is 'vi', which conflicts with 'Virgin Islands, U.S.'. The ISO 3166-2 presents 'vi' code virgin islands US. ISO 3166-2 code for Vietnam is 'vn' respectively.

Why don't you support 'vn' or make an alias or make a copy file?

When I give this command rails g devise:views:locale pt-BR it generates a devise.views.pt-BR.yml file instead of devise.pt-BR.yml. So if I create a devise.pt-BR.yml file it does not recognize and continues with the standard gem translation. If I change this file or create one with the devise.views.pt-BR.yml name works.

@JasonBarnabe I noticed one really weird thing. This commit changes "Sign in" to "Log in", even though "sign in", "signed in" is used all around (even the key is sign_in). I see no reason for using a different, inconsistent wording for that. Would you be open to me updating it in Localeapp?