GetApplicationContext()->GetApplicationLocale() returns the wrong locale |
|||||
Issue descriptionChrome Version: 63.0.3223.0 OS: iOS What steps will reproduce the problem? (1) Go to Settings > General > Language and Region > iPhone Language (2) Change the language to English (New Zealand) (3) Go to https://rsolomakhin.github.io/pr/contact/ and press Buy. (4) Add a new contact info. (5) Start typing in a fake number into the Phone Number* field (e.g., 555...) What is the expected result? The phone number should be formatted with the +64 (New Zealand) country code. What happens instead? The phone number gets formatted with the +44 (UK) country code. Payment Request calls GetApplicationContext()->GetApplicationLocale() to obtain the currency locale. This call returns "en-GB" instead of "en_NZ". Same issue happens for India, Ireland, South Africa and other english speaking countries except Canada and US.
,
Sep 25 2017
,
Sep 25 2017
,
Sep 27 2017
I think this is only happening on iOS 11. With previous version of iOS, the phone rebooted when the locale was changed, but it appear to no longer be the case with iOS 11. As GetApplicationContext()->GetApplicationLocale() value is set on a cold start, it is not refreshed when the OS changes its language setting. There may be other part of the application that are broken due to this (the OS not rebooting after a change in locale) due to the same caching of the locale/language.
,
Sep 28 2017
My commend #4 is incorrect, the app is correctly restarted when the language is changed. The issue is that GetApplicationLocale() returns only a language from those supported by Chrome on iOS (full localisation, see build/config/locales.gni for the list and l10n_util::OverrideLocaleWithCocoaLocale for the code computing the closest language). So when the user selects a language that is not supported by the Chrome localisation, the closes supported language is selected. There is the following comment above this code (refers to Mac OS X but the same behaviour is implemented on iOS as the code is shared): // Chrome really only has one concept of locale, but Mac OS X has locale and // language that can be set independently. After talking with Chrome UX folks // (Cole), the best path from an experience point of view is to map the Mac OS // X language into the Chrome locale. This way strings like "Yesterday" and // "Today" are in the same language as raw dates like "March 20, 1999" (Chrome // strings resources vs ICU generated strings). This also makes the Mac acts // like other Chrome platforms. See NSBundle -preferredLocalizations. The list of supported localisations is: ar, bg, ca, cs, da, de, el, en-GB, en-US, es, fa, fi, fr, he, hi, hr, hu, id, it, ja, ko, lt, ms, nb, nl, pl, pt-PT, ro, ru, sk, sr, sv, th, tr, uk, vi, zh-CN, zh-TW, es-MX, pt. So the code is behaving as intended. If for your use case you want a different locale, you can use NSLocale +currentLocale, but you should probably contact UX first. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by mahmadi@chromium.org
, Sep 25 2017