Currently, navigator.language is the thing that we use as the BCP-47 tag in our Intl code when certain APIs are called without a locale argument. That mostly based sense, and is deeply wired into our engine. In bug 156993, we made Intl aware of the region as a separate thing from the language by having platformUserPreferredLanguages() return something like a BCP-47 tag that was <language>-<region>. For example, if I told System Preferences that I want to speak English in Poland then we'd get "en-pl". This had the effect of making Intl APIs format dates using Polish formatting, for example. But this is an odd change, since that same function also feeds into navigator.language. "en-pl" isn't what we want there, since my System Preferences settings did not mean to imply that I want to speak Polish-style English. I don't think there is such a thing as Polish-style English (except in funny jokes, maybe). It may be worthwhile to wire the region settings more elegantly into Intl, but if we do that, it should be via a mechanism that is separate from navigator.language.
Created attachment 283463 [details] the patch
Comment on attachment 283463 [details] the patch rs=me We don't need to revert API tests, do we?
(In reply to comment #2) > Comment on attachment 283463 [details] > the patch > > rs=me > > We don't need to revert API tests, do we? We may have to. I will run them and see!
(In reply to comment #3) > (In reply to comment #2) > > Comment on attachment 283463 [details] > > the patch > > > > rs=me > > > > We don't need to revert API tests, do we? > > We may have to. I will run them and see! Yeah we have to. I will revert https://trac.webkit.org/changeset/200105/trunk/Tools/TestWebKitAPI/Tests/mac/NavigatorLanguage.mm.
Created attachment 283465 [details] patch for landing Also reverted the API test.
Landed in https://trac.webkit.org/changeset/203141
<rdar://problem/27313190>