What exactly are the effects of "allow user locale"

There are several points in the server code that call I18n.with_locale(user.effective_locale) including the email jobs.

1 Like

I have no idea how to delete the translations of the bot at the command line, but I tried deleting them under /admin/customize/site_texts/ but unfortunately, trying to submit an empty field leads to a 422 error. Any other way how I can achieve this?

Could this be done with some monkey patch plugin? If so, I would appreciate some pointers as to where to start…

Regardless of quick fixes, is there a chance that there will be a site setting that enforces the bot to ignore all user locales and stick to the site locale?

Nope that is the intended behavior. The user’s locale is configured before the start of each request server side and that has been the way all along.



Okay, I can see the intention behind that, but do you really think that anymore than 0.001 percent of discourse sites will be able to customize the bot in all languages?

I think we need to clear things up a little here. My understanding is that if allow user locale is enabled, all text that is sent/displayed to the user either from the server or the client is going to be in the locale that the user has selected. Maybe @zogstrip can confirm because I don’t think it is a bug that text generated on the server is using the user’s selected locale.

Also this isn’t specific to just the bot, you can customize an email template and you’ll be faced with the same problem. What I think the right fix here is that if you customize a translation of the default site locale, all the other locales should treat its corresponding translation text as missing so that it fallbacks and uses the customized text of the default locale.


True, I just focused on the bot because that’s the problem I’m currently facing and which I thought is most likely relevant to many sites because I assume that most will customize the bot’s first message (although the need for this could be reduced if it were possible to have the bot plus a welcome email).

Excellent idea! I might add: treat as missing unless the corresponding copy has also been customized.

The extra benefit of this solution would also be that it facilitates complaint driven improvement of discourse sites: “Why is X being shown in English when everything else is in my preferred language?” -
"It’s because we don’t speak all languages. Could you give us a translation and we’ll fix it. "

I fact, one could even add a mouse-over hint or something like that, encouraging users to submit their translation. If your suggested fix gets implemented, could you make sure those fallback texts get their own class?

1 Like

I feel very strongly it is the responsibility of the person customizing to deal with all the languages they care about, if it is that important to them.

That would require that admins can limit which locale their users can choose. That would also be a solution, but it would prevent communities from benefiting from the increasing number of translations that discourse provides out of the box.

You are fixating on problems specific to you, that is, you believe that customizing text in one language should somehow magically customize the same text in every available human language. I do not share this belief and I feel, very strongly, that you should bear the burden of your own choices with regards to text customization. If you want to customize text in every language, you take responsibility for that work, not us.

Furthermore, I also fail to share your belief that non-customized text is some kind of disaster of epic proportions. Default text is harmless.

My reply was actually based on my understanding of the code when I last changed it. I guess it was a while back :wink: I very much prefer that we are now consistent across all UI text even though it means more work on admins when they customize some text. I also :+1:t2: your suggestion.


No, this is a misunderstanding. I am merely looking for a way to allow users to use existing locales while still allowing site admins to customize texts, especially the discobot welcome message. Currently, you have the choice of either allowing user locales or customizing.

I have said nothing to convey such a belief. However, default text can be a problem under certain circumstances, for example when you have customized the welcome message to provide certain site specific information to new users but then some users nevertheless receive the default welcome message.

Untrue, you can customize in both cases. Just not to your satisfaction.

Simply customize all affected locales, this already works.

Since you cannot exclude any locales, that would be “all locales”, which brings us back to

Why not just customize it in the ~4 most common languages after English? Surely you’re not going to have users speaking American Cherokee Indian anytime soon.

Yes, as I said, limiting the locales that users can choose would also solve the problem, albeit in an unnecessarily limiting way.

What do you think about @tgxworld’s proposal above?

I don’t know about this. A new user wouldn’t have had the chance to select her/his preferred locale before the welcome message is sent out. I’m pretty sure they are most likely going to get your customised message in the default locale of the site.

Unless you have set locale from accept language header turned on :wink:
Or if users choose to respond to the bot after they have customized their locale (though that would not concern the welcome message)

1 Like

If you’re knees deep into customisations, wouldn’t it be better to just turn off set locale from accept language header ? Even with my proposed fix for your use case, they are going to end up getting the welcome message in the default locale of your site. I don’t feel very strongly about this and like @codinghorror said, customising the welcome message for the 4 next common languages would be good enough.

1 Like

Yes, I did that, of course, when I realized the consequences. But I think it’s a really great setting for multi-lingual sites because it immediately sends a message to new users when they first visit the site. In fact, even on mono-lingual sites, people who are not native speakers of the site language might be attracted by having the UI in another language.

Yes, unless their browser locale is in one of the languages for which I customized the message. But that, I think, is fine because on the plus side, what users get is the whole UI in their language. You can’t have it all. And you might even speculate that if that UI brings more people from that language community to my forum, chances are that eventually someone helps translate the welcome message (or whatever else is missing).

Since this would also require a new feature (limiting which locales are available on a site) I guess it’s a matter of cost/benefit calculation. The benefit of limiting user locales would be tangible but rather limited and with negative side effects (but still a viable solution). The benefit of your suggestion would be great and would increase in time as more discourse locales become available. So, in my mind, it is clearly the better solution in terms of benefit and openness for future development.

I have no clue about the cost dimension. Could you add it to the equation?

SInce this topic has been somewhat inconclusive I’d like to return to what I think was an excellent suggestion:

This would be immensely helpful and as far as I can tell (which is not very far) it’s probably a rather easy thing to accomplish. Any chance that this could get implemented?

Just to reiterate why this is useful, since the discussion above is somewhat complex: basically, it solves the problem that once you customize any text element in your site’s default language, you can no longer allow users to choose their own locale (let alone enable set locale from accept language header) because they will be seeing the default texts in their respective language and those will no longer correspond to the texts in the site’s main language.

I should add one important detail to the proposed solution:

if you customize a translation of the default site locale, all the other locales should treat its corresponding translation text as missing unless the translation text has also been customized

In other words: if my site is in English and I customized a specific text in English but also in French, all locales will fall back to the default locale for that specific text except for the French locale, (because it has also been customized so that a correspondence between the translations can be assumed).