Changeset 203141 in webkit


Ignore:
Timestamp:
Jul 12, 2016 5:05:25 PM (8 years ago)
Author:
fpizlo@apple.com
Message:

platformUserPreferredLanguages on Mac should not try to put the region into the language
​https://bugs.webkit.org/show_bug.cgi?id=159693

Rubber stamped by Alexey Proskuryakov.

Source/WTF:

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 makes sense, and is
deeply wired into our engine.

In r200105, 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
but live 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 aren't supposed to
mean that I want to speak Polish-style English. There's no such thing.

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. So, this change simply
reverts r200105.

  • wtf/PlatformUserPreferredLanguagesMac.mm:

(WTF::httpStyleLanguageCode):
(WTF::platformUserPreferredLanguages):
(WTF::isValidICUCountryCode): Deleted.

Tools:

Revert the test change in r200105.

  • TestWebKitAPI/Tests/mac/NavigatorLanguage.mm:

(TestWebKitAPI::languageForSystemLanguage):

Location:
trunk
Files:
4 edited

Legend:

Unmodified
Added
Removed

  • trunk/Source/WTF/ChangeLog

    r203134 r203141  
     12016-07-12  Filip Pizlo  <fpizlo@apple.com>
     2
     3        platformUserPreferredLanguages on Mac should not try to put the region into the language
     4        https://bugs.webkit.org/show_bug.cgi?id=159693
     5
     6        Rubber stamped by Alexey Proskuryakov.
     7       
     8        Currently, navigator.language is the thing that we use as the BCP-47 tag in our Intl code
     9        when certain APIs are called without a locale argument.  That mostly makes sense, and is
     10        deeply wired into our engine.
     11
     12        In r200105, we made Intl aware of the region as a separate thing from the language by having
     13        platformUserPreferredLanguages() return something like a BCP-47 tag that was
     14        <language>-<region>.  For example, if I told System Preferences that I want to speak English
     15        but live in Poland then we'd get "en-pl".  This had the effect of making Intl APIs format
     16        dates using Polish formatting, for example.
     17
     18        But this is an odd change, since that same function also feeds into navigator.language.
     19        "en-pl" isn't what we want there, since my System Preferences settings aren't supposed to
     20        mean that I want to speak Polish-style English.  There's no such thing.
     21
     22        It may be worthwhile to wire the region settings more elegantly into Intl, but if we do that,
     23        it should be via a mechanism that is separate from navigator.language. So, this change simply
     24        reverts r200105.
     25
     26        * wtf/PlatformUserPreferredLanguagesMac.mm:
     27        (WTF::httpStyleLanguageCode):
     28        (WTF::platformUserPreferredLanguages):
     29        (WTF::isValidICUCountryCode): Deleted.
     30
    1312016-07-12  Per Arne Vollan  <pvollan@apple.com>
    232

  • trunk/Source/WTF/wtf/PlatformUserPreferredLanguagesMac.mm

    r201038 r203141  
    7878namespace WTF {
    7979
    80 static String httpStyleLanguageCode(NSString *language, NSString *country)
     80static String httpStyleLanguageCode(NSString *language)
    8181{
    8282    SInt32 languageCode;
    … …  
    8585    CFStringEncoding stringEncoding;
    8686   
    87     bool languageDidSpecifyExplicitVariant = [language rangeOfCharacterFromSet:[NSCharacterSet characterSetWithCharactersInString:@"-_"]].location != NSNotFound;
    88 
    8987    // FIXME: This transformation is very wrong:
    9088    // 1. There is no reason why CFBundle localization names would be at all related to language names as used on the Web.
    … …  
    9896    // Make the string lowercase.
    9997    NSString *lowercaseLanguageCode = [language lowercaseString];
    100     NSString *lowercaseCountryCode = [country lowercaseString];
    101    
    102     // If we see a "_" after a 2-letter language code:
    103     // If the country is valid and the language did not specify a variant, replace the "_" and
    104     // whatever comes after it with "-" followed by the country code.
    105     // Otherwise, replace the "_" with a "-" and use whatever country
    106     // CFBundleCopyLocalizationForLocalizationInfo() returned.
     98       
     99    // Turn a '_' into a '-' if it appears after a 2-letter language code
    107100    if ([lowercaseLanguageCode length] >= 3 && [lowercaseLanguageCode characterAtIndex:2] == '_') {
    108         if (country && !languageDidSpecifyExplicitVariant)
    109             return [NSString stringWithFormat:@"%@-%@", [lowercaseLanguageCode substringWithRange:NSMakeRange(0, 2)], lowercaseCountryCode];
    110        
    111         // Fall back to older behavior, which used the original language-based code but just changed
    112         // the "_" to a "-".
    113101        RetainPtr<NSMutableString> mutableLanguageCode = adoptNS([lowercaseLanguageCode mutableCopy]);
    114102        [mutableLanguageCode.get() replaceCharactersInRange:NSMakeRange(2, 1) withString:@"-"];
    … …  
    117105
    118106    return lowercaseLanguageCode;
    119 }
    120 
    121 static bool isValidICUCountryCode(NSString* countryCode)
    122 {
    123     if (!countryCode)
    124         return false;
    125     const char* const* countries = uloc_getISOCountries();
    126     const char* countryUTF8 = [countryCode UTF8String];
    127     for (unsigned i = 0; countries[i]; ++i) {
    128         const char* possibleCountry = countries[i];
    129         if (!strcmp(countryUTF8, possibleCountry))
    130             return true;
    131     }
    132     return false;
    133107}
    134108
    … …  
    148122
    149123    if (userPreferredLanguages.isEmpty()) {
    150         RetainPtr<CFLocaleRef> locale = adoptCF(CFLocaleCopyCurrent());
    151         NSString *countryCode = (NSString *)CFLocaleGetValue(locale.get(), kCFLocaleCountryCode);
    152        
    153         if (!isValidICUCountryCode(countryCode))
    154             countryCode = nil;
    155        
    156124        RetainPtr<CFArrayRef> languages = adoptCF(CFLocaleCopyPreferredLanguages());
    157125        CFIndex languageCount = CFArrayGetCount(languages.get());
    … …  
    160128        else {
    161129            for (CFIndex i = 0; i < languageCount; i++)
    162                 userPreferredLanguages.append(httpStyleLanguageCode((NSString *)CFArrayGetValueAtIndex(languages.get(), i), countryCode));
     130                userPreferredLanguages.append(httpStyleLanguageCode((NSString *)CFArrayGetValueAtIndex(languages.get(), i)));
    163131        }
    164132    }

  • trunk/Tools/ChangeLog

    r203129 r203141  
     12016-07-12  Filip Pizlo  <fpizlo@apple.com>
     2
     3        platformUserPreferredLanguages on Mac should not try to put the region into the language
     4        https://bugs.webkit.org/show_bug.cgi?id=159693
     5
     6        Rubber stamped by Alexey Proskuryakov.
     7       
     8        Revert the test change in r200105.
     9
     10        * TestWebKitAPI/Tests/mac/NavigatorLanguage.mm:
     11        (TestWebKitAPI::languageForSystemLanguage):
     12
    1132016-07-12  Chris Dumez  <cdumez@apple.com>
    214

  • trunk/Tools/TestWebKitAPI/Tests/mac/NavigatorLanguage.mm

    r200105 r203141  
    6969}
    7070
    71 // These tests document current behavior. Some of the current results may not be right. Note that
    72 // this oddly assumes that the user has set their language to something possibly-foreign but still
    73 // left their region as US. Hence the "-us" variants.
    74 // FIXME: These tests should also set the region to see how WebKit will handle that.
    75 // https://bugs.webkit.org/show_bug.cgi?id=157039
     71// These tests document current behavior. Some of the current results may not be right.
    7672NSArray *tests = @[
    77     @[@"ru", @"ru-us"], // This does not match other browsers or CFNetwork's Accept-Language, which all use "ru".
     73    @[@"ru", @"ru-ru"], // This does not match other browsers or CFNetwork's Accept-Language, which all use "ru".
    7874    @[@"en", @"en-us"],
    7975    @[@"en-GB", @"en-gb"],
    8076    @[@"en-US", @"en-us"],
    81     @[@"ja", @"ja-us"],
    82     @[@"hi", @"hi-us"],
     77    @[@"ja", @"ja-jp"],
     78    @[@"hi", @"hi-in"],
    8379    @[@"zh-TW", @"zh-tw"], // This should not map to the generic zh-hant, see rdar://problem/21395180.
    8480    @[@"zh-HK", @"zh-tw"],
    85     @[@"es", @"es-us"],
     81    @[@"es", @"es-es"],
    8682    @[@"es-MX", @"es-xl"],
    8783    @[@"es-ES", @"es-es"],
    … …  
    9187    @[@"pt-BR", @"pt-br"],
    9288    @[@"pt-PT", @"pt-pt"],
    93     @[@"fr", @"fr-us"],
     89    @[@"fr", @"fr-fr"],
    9490    @[@"fr-CA", @"fr-ca"],
    9591];
Note: See TracChangeset for help on using the changeset viewer.