What exactly are the effects of "allow user locale"

Feature
,
1

I have a specific question about “allow user locale” but I thought I might as well broaden it for general interest.

In particular, I would like to understand whether enabling “allow user locale” by itself will change the language of the welcome message and other system messages as well as the discobot (provided that the user chooses a different locale to the default one).

More generally, it would be good t understand the effects of this setting (plus users changing locale)…

I have so far opted to leave user locale disabled because I am customizing various Text Content snippets but so far I am doing this only in English so that I need to make sure that all users will get the English version of these messages. But now the Discours-Translator plugin requires “allow user local” to be enabled. Hence the question…

1 Like
2

I believe this only changes UI translations, not the content of any messages sent.

3 Likes
3

The user locale should only override the UI translations. If it does more, then it’s a :bug:

4 Likes
4

Okay, then there is a bug. I recently enabled set locale from accept language header and just realized that the bot started sending its welcome message in different languages, not just the site’s default language, which is English.

The problem with this is that the messages in other languages differ to a great extent from the English ones (whichbI customized). So I rushed to turn off the automatic locale detection but I would love to turn it back on…

Maybe it’s sufficient, for the time being, to simply force the bot to to always use the default site locale?

Oh, and what happens if I manually edit the bot’s message that was delivered in, say German, and paste in the English content like it should have been? Will that work or will the bot continue in German anyway?

5

If you customize a text, you need to customize it on every language you site visitors use.

3 Likes
6

So what @zogstrip said is not correct?

7

Unless something has recently changed, selecting allow user locale will translate a user’s notifications.

8

The question is what exactly that means. And if it really means that not just the UI is translated as indicated above, then I’d say this is a problem as it basically makes it impossible to allow user locales once I customize any text content element under /admin/customize/site_texts because I don’t see how any site admin would be able to maintain translations of, for example, the welcome message, in all languages.

If it is so that not all customizable text elements depend on user locale, then I think part of the confusion could be resolved if each text element would be displayed with a label indicating whether this is rendered based on default site locale or based on user locale.

9

The intention behind it was to send email notifications in the user’s locale. I’m only aware of it affecting the email notifications that are created in user_notifications.rb - things like the account created and password reset email.

10

Aha! Email notifications! That’s yet another story, making things even more complicated. I’m starting to thing that we need a setting allowing the site owner to specify the scope of the user locale or something. Because for those who leave email messages as they are, having them sent out in the user’s language is just fine. But if you make some adjustments specific to your site, you will want to make sure that they are sent out in the site’s default language, regardless of user locale.

This can be discussed in more detail (e.g. what if, by default, un-customized copies are rendered according to user locale but customized copies but customized one’s are rendered in the site’s default language? This can lead to a mess, when a message includes several copies, though…) but before doing that, it would be great to get some clarifications from the @team regarding the current state of affairs.

1 Like
11

Yes, this is a good idea. It would also make the ‘set locale from accept language header’ setting a lot more workable. It’s unlikely that any multi-lingual forum would need more than a few languages.

1 Like
12

What I meant by scope was actually: which copies are translated and which ones remain in the default language (rather than: which languages are translated and which are treated as default)

13

I confirmed that the bot always replies in the current user locale language (or the default, if no translation exists in that language), regardless of what language it previously used.

While in an ideal world, this could be seen as a feature, I think it currently causdy problems than it solves. And, apparently it wasn’t even intended, if I understood @zogstrip correctly.

So: is there a quick fix that I could apply to force the bot to ignore the user locale for the time being?

For example, I could delete all existing translations of the bot on my instance to force it to fall back on the site default. But how do I do that? And how can I prevent the translations from coming back at the next update?

14

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

1 Like
15

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?

16

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.

4 Likes
17

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?

18

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.

8 Likes
19

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
20

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.