Some additional context:
We determined that one thing that does play a big role in Windows is the installer itself.

If you download stable Chrome from an english page, it triggers and english installer which will default to english. Similarly, if you start with a french download page, it will default to french.

This seems... ok, but unusual that the system language is overridden in this context. Not sure what is right.

As well, we noticed that on Windows you can change the default language in settings, but not in Linux

On Mac it's also not possible to change Chrome's language independently of the system one either.

The code for all of this is pretty platform specific:

https://cs.chromium.org/chromium/src/ui/base/l10n/l10n_util.cc?rcl=e98161eb3fcb6d04c6fabe32e4048a188dd70f19&l=428

On Windows, as comment 1 notes, the default language of Chrome is set entirely by the installer.  After that the language setting is internal to Chrome; the browser never has a concept of system language.

I can't speak to anything about how Mac and Linux work.  I don't have a strong opinion on best practice here.  Be careful about what accept-languages are passed to web pages as that can affect content area defaults.

"the browser never has a concept of system language."

I don't think this is quite correct. For example, rkaplow@ built TOT official build (w/ out going through installer) on a system with language set to French. With an empty user data dir it was in French. Which suggests that it does detect if from OS.

Also, my understanding that the code I linked to is also doing that via l10n_util::GetLocaleOverrides(). Which is set up via OverrideLocaleWithUILanguageList(). Which calls GetThreadPreferredUILanguageList(), which is documented as:

// Adds to |languages| the list of thread, process, user, and system preferred
// UI languages from MUI, if available, falling-back on the user default UI
// language otherwise.

+grt who might know more about the interaction with installer

I suspect there is a complicated history with languages in Chrome.

There's MacOS, Linux, and I think CrOS, which pick up the UI language from the system, and then there's Windows, which does not.

In MacOS, Linux, and CrOS, users are free to change the UI language at will and apps generally participated, so it made sense for Chrome to simply use the system language.

On Windows, however, the ability to switch the UI language used to only be restricted to the higher end SKUs (Win 7 Ultimate). With later versions of Windows, this ability propagated to most, if not all SKUs.

Making the story more difficult is that many users run en-US Windows even though they may not speak English or aren't in the United States. These users may also not have the ability to change the language on the machine due to the SKU restriction.

As a result, apps on Windows have generally had to take matters into their own hands with regards to UI language. Skype is an example of an app, that even though it is now Microsoft's, maintains a separate UI language setting that can deviate from the system language.

Making this even more complicated is the fact that many Google properties autodetect the locale and language based off of IP and occasionally ignoring the Accept-Language directive provided by the user-agent (since after all, many users use en-us Windows).

So what does that mean for Chrome on Windows? There are a few ways forward (not all of the below are great solutions):
1) Introduce the ability to have Chrome follow the System UI language for SKUs that support it (we'll still need today's behavior as an escape hatch if the user can't change the language for whatever reason).

2) Start respecting Accept-Language more and default to using the System UI Language at all times permitting an escape hatch (I'm not sure I'm thrilled about this).

3) Keep the behavior today based on an assumption that the common case is that users directly download the installer from the Chrome website and the website selects the correct language for the user.

So some more notes on the actual behavior:

The kApplicationLocale pref will be set based on what the installer sets in the registry on first run. And if this is set (and valid) Chrome will use this as the language on Windows. But if it's not set, or not valid, it will then default to system language. One case where it might not be set is when you just build your own Chrome locally - or clear registry values manually.

That's pretty much it. For consumer installs of Chrome, we use the language of the dlpage as the startup language of the browser: the dlpage tags the installer with lang=LL, Google Update reads this from the tag and writes it into Chrome's ClientState key in the registry before it installs Chrome, then Chrome's installer uses this as the preferred language for its own work and Chrome, on first-run, uses this value as the initial kApplicationLocale value.

This is not a localization issue (can't be fixed by our linguists). It's more of a feature issue.

My read here is there is not immediate action we can take here and we have a better understanding of how a particular language is set for Chrome.

As such, I'm making this WontFix. If there is something that I missed, feel free to reopen and comment.