Title: [201066] trunk/Source/_javascript_Core
Revision
201066
Author
fpi...@apple.com
Date
2016-05-17 19:11:19 -0700 (Tue, 17 May 2016)

Log Message

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):

Modified Paths

Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (201065 => 201066)


--- trunk/Source/_javascript_Core/ChangeLog	2016-05-18 02:07:11 UTC (rev 201065)
+++ trunk/Source/_javascript_Core/ChangeLog	2016-05-18 02:11:19 UTC (rev 201066)
@@ -1,3 +1,28 @@
+2016-05-17  Filip Pizlo  <fpi...@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  <d...@apple.com>
 
         Remove ES6_GENERATORS flag

Modified: trunk/Source/_javascript_Core/runtime/IntlObject.cpp (201065 => 201066)


--- trunk/Source/_javascript_Core/runtime/IntlObject.cpp	2016-05-18 02:07:11 UTC (rev 201065)
+++ trunk/Source/_javascript_Core/runtime/IntlObject.cpp	2016-05-18 02:11:19 UTC (rev 201066)
@@ -1,6 +1,7 @@
 /*
  * Copyright (C) 2015 Andy VanWagoner (thetalecraf...@gmail.com)
  * Copyright (C) 2015 Sukolsak Sakshuwong (sukol...@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 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;
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to