Weird, are you setting your language with something like this?
I have found sometimes the ordering on the Chrome language selector doesn’t stick where it should.
If it’s still not working could you check what the Accept-Language parameters are? In chrome, right-click on the page, select Inspect Element. On the window that pops up select Network and then click on one of the poll requests from the left-hand menu. It should look something like this:
OK, I see the problem, which is that the browser had preserved some of its language settings, but not all of them. Any way to have this detect system/OS language?
edit: thanks for all the troubleshooting help BTW, it’s really incredible
4 Likes
I don’t think so.
If you’re using this in production, make sure to update to the latest version. In the previous version it was throwing an error if the accept-language header wasn’t set.
Nice to have such a plugin. Would you mind to post the link once again to the category section or move this topic to the plugin category? 
There’s some talk about adding something like this to the Discourse core. Most of the major sites I look at (facebook, twitter, google etc.) are doing something similar. One difference is that they seem to be overriding the http headers if a user’s locale has been set in a cookie.
If nothing is happening with this I will post it to the plugins category.
2 Likes
It would be great if this could be included in core. 
2 Likes
@erlend_sh can you confirm with @simon the plan here? Would love to fund this work with the Mozilla grant.
I just refined this a bit:
https://github.com/discourse/discourse/commit/759803708077dc061ec4449395abb3505486e4fd
This gem was injecting extra middleware and adding stuff on our application controller. I changed it so it has no impact for users not using the feature.
2 Likes
Seems that not all of @simon’s code gets merged into core.
For example, the current:
where effective_locale is:
https://github.com/discourse/discourse/blob/master/app/models/user.rb#L207-L213
is missing certain features from @simon’s original plugin code:
https://github.com/scossar/accept-language/blob/master/plugin.rb#L27-L49
In particular, this part:
elsif SiteSetting.accept_language_overrides_default_locale
I18n.locale = locale_from_http_header
So, in other words, a logged in user does not get this auto-language-detection benefit.
@simon’s plugin has not been updated for 2 years and I’m not sure how well it works with the current Discourse version… otherwise it would be perfect.
1 Like
That’s intentional. If ‘allow user locale’ is also enabled, the user’s locale will be set when they register, so it will be set from the accept language header.
Are you sure? Because I’ve seen ALL my users’ interface language being default. Only a few of them knew to change it in profile.
And they all came from invites, not public registration. I’m pretty sure it only asked for:
- username
- nickname
- password
when they first sign on.
Yes, it should work that way when both ‘allow user locale’ and ‘set locale from accept language header’ are enabled. I just tested it with my browser’s preferred language set to french, and it created a user with their preferred locale set to french.
That will be the problem.
1 Like
Yes, the invite sign-on form seems to be different from the public sign-up…
This is the invite sign-on when creating a user:
Language is not specified.
The locale isn’t on the signup form. I haven’t looked at the code for a while, but from what I remember, it’s set from the locale. This means that if the locale has been set from the header, that locale will be set for the user.
Yes, but effective_locale has nothing to do with the accept-language header. Evident from this code:
https://github.com/discourse/discourse/blob/master/app/models/user.rb#L207-L213
Sorry, I edited my post. It’s set from the locale, which is set from the header.
Nope. I don’t think so. At least not for invite.redeem.
Check this:
Maybe for new user sign-up.