I also use non-English region & location settings in Windows with English UI so I can confirm the change in Chrome's behavior doesn't make any sense for this use case.

Bisected to 875789eaa469e365ac6fb7ac069f4ca6c0676cee = https://crrev.com/c/898070 by sky@chromium.org
"reland: Moves loading of local_state and field trials to early initialization"

woxxom@, thank you so much for the quick bisect.

sky@, can you please look into this change (https://chromium-review.googlesource.com/c/chromium/src/+/898070) ?

The same behavior for 64-bit version.

+ privard@ - is this really a blocker? Or was this intended?

I'm not aware of any planned changes to this behavior. As far as I can tell, it's a bug. sky@, is there any chance we can include a patch for this in a re-spin?

Followed-up with privard@ this shouldn't block ramp-up; however, let's continue to understand why this launched and potentially consider a patch (if there is respin). 

Hey all,

We're also seeing reports of similar behavior on the consumer community side. Specifically, we've spotted reports of new installs defaulting to non-English languages, and reports of the M66 update reseting the preference for *existing* Chrome installations.

Threads:
- https://productforums.google.com/forum/#!topic/chrome/NPVVRgfDWbY
- https://productforums.google.com/forum/#!topic/chrome/WGppyBeZeS8
- https://productforums.google.com/forum/#!topic/chrome/IKWB43k6cJo

Feedback Reports:
- https://listnr.corp.google.com/report/85341051388
- https://listnr.corp.google.com/report/85340944910
- https://listnr.corp.google.com/report/85340916921

For users seeing their preference change automatically with the update, that can be pretty jarring behavior =\

Thanks!

jam@ can you help get this prioritized? we should get this in respin next week. 

Can someone elaborate on what the expectations are here? Comment #1 says:

Steps to reproduce the problem:
1. Install googlechromestandaloneenterprise.msi on Windows 7 with Norwegian localization
2. Run Chrome
3. Chrome appears with Norwegian UI

Where as previously step 3 was:
3. Chrome always started with English UI language at first launch

Can someone elaborate on why the expectation is Chrome always start in English? If the user is in a Norwegian locale, wouldn't they expect Norwegian UI?

>Can someone elaborate on why the expectation is Chrome always start in English?

Because "locale" is not UI and their Windows UI is English, all (or most of) their apps are probably in English too.

Assuming no overriding settings for the language are specified, I think the *only* correct solution is to use the display language chosen by the user in the Windows Control Panel for regional settings and localization.
There's a WINAPI function to get it:
GetUserDefaultUILanguage
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318137(v=vs.85).aspx

   Returns the language identifier for the user UI language for the current user.
   If the current user has not set a language, GetUserDefaultUILanguage returns the preferred language set for the system. 
   If there is no preferred language set for the system, then the system default UI language (also known as "install language") is returned.

In Chromium source code it's used currently only by LanguageSelector, whatever that is.

I see the issue. BrowserMainLoop needs to call OverrideLocaleWithUILanguageList() before it calls PreEarlyInitialization().

Thanks for more details woxxom@ and sky@ for looking into this. If we can land something in trunk by tonight, this will allow us to consider this for a respin this week. 

I'm bumping this to a 1.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d95d2408c4f2fd067abc806e0cab477f27e378a3

commit d95d2408c4f2fd067abc806e0cab477f27e378a3
Author: Scott Violet <sky@chromium.org>
Date: Tue Apr 24 01:03:21 2018

windows: call l10n_util::OverrideLocaleWithUILanguageList() earlier

As part of  bug 800358  I moved loading ResourceBundle earlier
(specificaly to PreEarlyInitialization()). Unfortunately I missed that
OverrideLocaleWithUILanguageList() needs to be called before
this. This means the locales were not being picked up correctly for
Windows. This patch moves calling OverrideLocaleWithUILanguageList()
to before PreEarlyInitialization() so that locales are properly
loaded.

I tried adding a DCHECK that the locales are set before
GetLocaleOverrides() is called, but that appears to break things.

BUG= 834372 
TEST=see bug

Change-Id: Idb40ee30761034a6c67ac153da3f9cebc9f7de40
Reviewed-on: https://chromium-review.googlesource.com/1025070
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#552935}
[modify] https://crrev.com/d95d2408c4f2fd067abc806e0cab477f27e378a3/content/browser/browser_main_loop.cc

I believe the fix for this has landed, but I have no way to verify. abdulsyed@chromium.org, could you find someone to verify the fix?

Unable to reproduce the issue on Windows 7 Enterprise (msi build) with chrome reported version-66.0.3359.117 & 65.0.3325.181 as per C#0,12 & 13.

Tested this issue with Chinese & Russian languages. Observed the same machine language(chinese/Russian) once we first launch of chrome. Chrome UI is not displayed in English for the first launch.

Note:
Unable to test with 'Norwegian' language as we are unable to setup this language.Tried in 2 to 3 machines (Corp & non corp).Hence requesting some one from MTV team to take a look into this issue with Enterprise chrome setup using 'Norwegian' language.

Thanks in advnce..!

FWIW, I confirm r552935 above has fixed the first run language selection for waterfall snapshot builds used by bisect-builds.py script.

Hello guys, similar problem here. 
After update Chrome to 66.0.3359.117, it started automated session not with English (which is Windows UI language), but with French (which is location). I changed location to UK, but still Chrome opens with French.

I think this issue related to Windows Format language (country). You can check it if set Location = France but Format (the previous tab) = Portugal (for example) in the previous version, then install 66.0.3359.117 version of Chrome and check language of browser. 
Also, if you set English lang as default , Portugal language will be removed from the list 

Yes, you are right. Format changed to EN and it starts with English, thank you. 
Anyway, I added language option in my test scripts, and it works regardless Windows settings.

M67 Stable promotion is coming soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.

A note to testers: for new installs, Chrome should start with the language of the download page. Please test this as well. The code to do so is here: https://cs.chromium.org/chromium/src/chrome/browser/chrome_browser_main.cc?type=cs&q=GoogleUpdateSettings::GetLanguage&sq=package:chromium&l=351.

+manoranjanr@ - can you please test this and verify fix in canary?

Seems like woxxom@ has already confirmed the fix on c#23.

sky@, can you please request a merge to 3359 branch?

Confirmed in #23, that this is in canary and tested. Approving merge to M66 branch:3359

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d885d116e0b0490bf42c89f3a80f1b65a82bce6d

commit d885d116e0b0490bf42c89f3a80f1b65a82bce6d
Author: Scott Violet <sky@chromium.org>
Date: Wed Apr 25 20:33:24 2018

windows: call l10n_util::OverrideLocaleWithUILanguageList() earlier

As part of  bug 800358  I moved loading ResourceBundle earlier
(specificaly to PreEarlyInitialization()). Unfortunately I missed that
OverrideLocaleWithUILanguageList() needs to be called before
this. This means the locales were not being picked up correctly for
Windows. This patch moves calling OverrideLocaleWithUILanguageList()
to before PreEarlyInitialization() so that locales are properly
loaded.

I tried adding a DCHECK that the locales are set before
GetLocaleOverrides() is called, but that appears to break things.

BUG= 834372 
TEST=see bug

Change-Id: Idb40ee30761034a6c67ac153da3f9cebc9f7de40
Reviewed-on: https://chromium-review.googlesource.com/1025070
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#552935}(cherry picked from commit d95d2408c4f2fd067abc806e0cab477f27e378a3)
Reviewed-on: https://chromium-review.googlesource.com/1028338
Cr-Commit-Position: refs/branch-heads/3359@{#766}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/d885d116e0b0490bf42c89f3a80f1b65a82bce6d/content/browser/browser_main_loop.cc

CL list at #36 also need a merge to M67. Pls request a merge ASAP. Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5bd6a03d53a0e52d658221232ae756b10efe59cb

commit 5bd6a03d53a0e52d658221232ae756b10efe59cb
Author: Scott Violet <sky@chromium.org>
Date: Wed Apr 25 21:05:59 2018

windows: call l10n_util::OverrideLocaleWithUILanguageList() earlier

As part of  bug 800358  I moved loading ResourceBundle earlier
(specificaly to PreEarlyInitialization()). Unfortunately I missed that
OverrideLocaleWithUILanguageList() needs to be called before
this. This means the locales were not being picked up correctly for
Windows. This patch moves calling OverrideLocaleWithUILanguageList()
to before PreEarlyInitialization() so that locales are properly
loaded.

I tried adding a DCHECK that the locales are set before
GetLocaleOverrides() is called, but that appears to break things.

BUG= 834372 
TEST=see bug

Change-Id: Idb40ee30761034a6c67ac153da3f9cebc9f7de40
Reviewed-on: https://chromium-review.googlesource.com/1025070
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#552935}(cherry picked from commit d95d2408c4f2fd067abc806e0cab477f27e378a3)
Reviewed-on: https://chromium-review.googlesource.com/1028495
Cr-Commit-Position: refs/branch-heads/3396@{#307}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/5bd6a03d53a0e52d658221232ae756b10efe59cb/content/browser/browser_main_loop.cc

M67 merge listed at #38 was approved via offline chat. Thank you for the quick merge.

Can this be marked as fixed if nothing else is pending?

Verified that it is fixed, on Windows 2012 R2: Chrome correctly uses the current display language.

Update: The bug is indeed fixed, but what I said in comment #42 was wrong since I misunderstood what the bug was. The problem is that i18n/l10n is kind of confusing, especially on Windows.

On Windows, under "Regional and Language Options", there are several settings:
- Format, which determines how numbers/dates/etc are displayed;
- Location, such as "United States";
- Display Language, which is the language that the UI is displayed with;
- System Locale;

These settings are independent of each other. E.g. you could have
- Format: "English (United States)"
- Location: "France"
- Display Language: "Chinese (Simplified, PRC)"
- System Locale: "German (Austrian)"

Now it's time to describe what the bug is: 
On a system where:
- Format is "German (Austria)"
- Display Language is "English (United States)"

Run Chrome.

Expected Behavior: The language used by Chrome is the Display Language, i.e. English.
Actual Behavior: The language used by Chrome is the one specified by Format, which is German in our case.

What I verified:
- Version 66.0.3359.117 shows this wrong behavior;
- In version 66.0.3359.139, this is fixed. When "Format" & "Display Language" are different, Chrome uses the Display Language.

I've just verified the behavior I mentioned in comment 30 above. Looks good to me.

feiling@ and grt@, thank you so much for the verification!