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.
لسماح بتعيين اللغة للمستخدمين المجهولين (غير المسجلين) بناءً على إعدادات لغة متصفحهم، يجب عليك تفعيل إعدادي “السماح للمستخدم بتعيين اللغة” و “تعيين اللغة من رأس Accept-Language”. توجد هاتان الإعدادتان في أعلى صفحة إعدادات “الإعدادات الأساسية” لموقعك.
بمجرد تفعيل هذين الإعدادين، سيتم تعيين واجهة مستخدم Discourse تلقائيًا للمستخدمين غير المسجلين إلى اللغة المفضلة التي حددوها في متصفحاتهم. وإذا قرر مستخدم غير مسجل إنشاء حساب على الموقع، فسيتم تعيين لغته تلقائيًا إلى اللغة المحددة في متصفحه. لاحظ أن هذا لن يعمل إلا إذا كانت لغته المحددة ضمن اللغات التي تمت ترجمة Discourse إليها.
لا يؤثر إعداد “تعيين اللغة من رأس Accept-Language” على المستخدمين الذين أنشأوا حسابات بالفعل على الموقع. بمجرد إنشاء الحساب، ستُعرض واجهة مستخدم Discourse باللغة المحددة في صفحة تفضيلات المستخدم. وطالما أن إعداد “السماح للمستخدم بتعيين اللغة” مفعّل، يمكن للمستخدمين الحاليين تحديث لغتهم هنا:
سؤال سريع حول هذا فيما يتعلق بمكون المترجم الإضافي. هل سيعمل المكون الإضافي للمترجم في هذا السيناريو إذا تم تعيين قيود ترجمة المكون الإضافي على “الجميع”؟
(نظرًا لأن اللغة المختلفة هي الشيء الذي يؤدي إلى ظهور زر الترجمة في المقام الأول)
فقط للعلم، لا أعتقد أن مجموعة “الجميع” تعمل بشكل صحيح مع إعداد المترجم هذا. وهي غير متاحة أيضًا للمجهولين، لذا فإن تعيينها على TL0 هي المجموعة الموصى بها لذلك.