This is also incorrect. I18n.locale is set from the header only if there is no logged in user. See here:
Now, I suspect that when the user first signs up, current_user is not set, thus kick-starting the whole get-the-language-from-header process, and then the I18n.locale got persisted into the user’s account.
However, this is certain NOT how it is done when a user redeems an invite.
Yes, if you look at users_controller you can see how it’s done differently.
Yup. I see it.
UsersController inherits from ApplicationController, which runs set_locale as a before_action.
That kick-starts the whole thing.
But users redeeming an invitation does not go through this.
Judging from this here:
Would this work:
user = invite.redeem(username: params[:username], name: params[:name], password: params[:password], user_custom_fields: params[:user_custom_fields])
if user.present?
user.locale = I18n.locale
user.save!
log_on_user(user)
post_process_invite(user)
end
Sorry for my Ruby – I don’t really know it. 
@david によるこのコミット以降、これで正常に動作するはずです 
皆さん、本当にありがとうございます。
でも……私にはもう一つ問題があるんです😔
使い方がわからないんです😣
匿名（未ログイン）ユーザーのブラウザ言語設定に基づいてロケールを自動設定するには、「ユーザーロケールの許可」と「Accept-Languageヘッダーからロケールを設定」の両方のサイト設定を有効にする必要があります。これらの設定は、サイトの「基本設定」ページの上の方にあります。
これらの設定を有効にすると、サイトへのログインを行っていないユーザーのDiscourseユーザーインターフェースは、ブラウザで設定された優先言語に自動的に切り替わります。未ログインのユーザーがアカウントを作成した場合、そのユーザーのロケールもブラウザで設定されたロケールに自動的に設定されます。ただし、Discourseが翻訳されている言語に設定されている場合のみ機能します。
「Accept-Languageヘッダーからロケールを設定」の設定は、すでにアカウントを作成済みのユーザーには影響しません。アカウント作成後、Discourseのユーザーインターフェースは、ユーザーの「設定」ページで指定されたロケールで表示されます。「ユーザーロケールの許可」設定が有効になっている限り、既存のユーザーはここでロケールを更新できます。
「Accept-Languageヘッダーからロケールを設定」については、手順（howto）トピックの作成が必要です。私はそのためのリマインダーを設定しており、まもなくトピックを作成します。
この件について、翻訳者プラグインとの関連で簡単な質問があります。プラグインの翻訳制限が「全員」に設定されている場合、このシナリオで翻訳者プラグインは機能しますか？
（そもそも翻訳ボタンが表示されるのをトリガーするのが異なるロケールであるということを考えると）
念のためお伝えしておきますが、「全員」グループは、その翻訳者の設定では正しく機能しないと思います。また、匿名のユーザーは利用できないため、TL0に設定することが推奨されるグループです。
