JSC should detect the right default locale even when it's not embedded in WebCore
authorfpizlo@apple.com <fpizlo@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 18 May 2016 02:11:19 +0000 (02:11 +0000)
committerfpizlo@apple.com <fpizlo@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 18 May 2016 02:11:19 +0000 (02:11 +0000)
https://bugs.webkit.org/show_bug.cgi?id=157755
rdar://problem/24665424

Reviewed by Keith Miller.

This makes JSC try to use WTF's platform user preferred language detection if the DOM did
not register a defaultLanguage callback. The result is that when JSC runs standalone it
will detect the platform user preferred language almost the same way as when it's embedded
in WebCore. The only difference is that WebCore may have its own additional overrides via
the WK API. But in the absence of overrides, WebCore uses the same WTF logic that JSC falls
back to.

We first found this bug because on iOS, the intl tests would fail because ICU would report
a somewhat bogus locale on that platform. Prior to this change, standalone JSC would fall
back to ICU's locale detection. It turns out that the ICU default locale is also bogus on
OS X, just less so. For example, setting things to Poland did not result in the jsc shell
printing dates Polish-style. Now it will print them Polish-style if your system preferences
say so. Also, the tests don't fail on iOS anymore.

* runtime/IntlObject.cpp:
(JSC::defaultLocale):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@201066 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Source/JavaScriptCore/ChangeLog
Source/JavaScriptCore/runtime/IntlObject.cpp

index 121c56f..c74fce4 100644 (file)
@@ -1,3 +1,28 @@
+2016-05-17  Filip Pizlo  <fpizlo@apple.com>
+
+        JSC should detect the right default locale even when it's not embedded in WebCore
+        https://bugs.webkit.org/show_bug.cgi?id=157755
+        rdar://problem/24665424
+
+        Reviewed by Keith Miller.
+        
+        This makes JSC try to use WTF's platform user preferred language detection if the DOM did
+        not register a defaultLanguage callback. The result is that when JSC runs standalone it
+        will detect the platform user preferred language almost the same way as when it's embedded
+        in WebCore. The only difference is that WebCore may have its own additional overrides via
+        the WK API. But in the absence of overrides, WebCore uses the same WTF logic that JSC falls
+        back to.
+        
+        We first found this bug because on iOS, the intl tests would fail because ICU would report
+        a somewhat bogus locale on that platform. Prior to this change, standalone JSC would fall
+        back to ICU's locale detection. It turns out that the ICU default locale is also bogus on
+        OS X, just less so. For example, setting things to Poland did not result in the jsc shell
+        printing dates Polish-style. Now it will print them Polish-style if your system preferences
+        say so. Also, the tests don't fail on iOS anymore.
+        
+        * runtime/IntlObject.cpp:
+        (JSC::defaultLocale):
+
 2016-05-17  Dean Jackson  <dino@apple.com>
 
         Remove ES6_GENERATORS flag
index e8d3c04..185beb5 100644 (file)
@@ -1,6 +1,7 @@
 /*
  * Copyright (C) 2015 Andy VanWagoner (thetalecrafter@gmail.com)
  * Copyright (C) 2015 Sukolsak Sakshuwong (sukolsak@gmail.com)
+ * Copyright (C) 2016 Apple Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -48,6 +49,7 @@
 #include <unicode/unumsys.h>
 #include <wtf/Assertions.h>
 #include <wtf/NeverDestroyed.h>
+#include <wtf/PlatformUserPreferredLanguages.h>
 
 namespace JSC {
 
@@ -645,11 +647,24 @@ String bestAvailableLocale(const HashSet<String>& availableLocales, const String
 String defaultLocale(ExecState& state)
 {
     // 6.2.4 DefaultLocale ()
+    
+    // WebCore's global objects will have their own ideas of how to determine the language. It may
+    // be determined by WebCore-specific logic like some WK settings. Usually this will return the
+    // same thing as platformUserPreferredLanguages()[0].
     if (auto defaultLanguage = state.callee()->globalObject()->globalObjectMethodTable()->defaultLanguage) {
         String locale = defaultLanguage();
         if (!locale.isEmpty())
             return canonicalizeLanguageTag(locale);
     }
+    
+    // If WebCore isn't around to tell us how to get the language then fall back to our own way of
+    // doing it, which mostly follows what WebCore would have done.
+    Vector<String> languages = platformUserPreferredLanguages();
+    if (!languages.isEmpty() && !languages[0].isEmpty())
+        return canonicalizeLanguageTag(languages[0]);
+    
+    // If all else fails, ask ICU. It will probably say something bogus like en_us even if the user
+    // has configured some other language, but being wrong is better than crashing.
     String locale = uloc_getDefault();
     convertICULocaleToBCP47LanguageTag(locale);
     return locale;