Bug 37733 - Managed culture settings out of sync with native culture settings
Summary: Managed culture settings out of sync with native culture settings
Status: CONFIRMED
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll (show other bugs)
Version: XI 9.1 (iOS 9.1)
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-01-15 16:47 UTC by Randall Schmidt
Modified: 2016-01-20 19:17 UTC (History)
2 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Reproduction case (only reproduces on certain iPads) (61.71 KB, application/zip)
2016-01-15 16:47 UTC, Randall Schmidt
Details
Screenshot of issue occurring (238.33 KB, image/png)
2016-01-15 16:47 UTC, Randall Schmidt
Details
iPad settings at time of occurance (332.72 KB, image/jpeg)
2016-01-15 16:48 UTC, Randall Schmidt
Details

Description Randall Schmidt 2016-01-15 16:47:05 UTC
Created attachment 14601 [details]
Reproduction case (only reproduces on certain iPads)

See the forum thread for pretty formatting: https://forums.xamarin.com/discussion/59203/app-launches-with-wrong-culture-settings-on-certain-ipads

I attached a reproduction case but it only reproduces on certain iPads.

--------------------

Xamarin Studio
Version 5.9.8 (build 0)
Installation UUID: 76cd4550-0ba3-46c2-9700-950d32dbe636
Runtime:
	Mono 4.0.5 ((detached/1d8d582)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 400050001

Xamarin.Android
Not Installed

Xamarin Android Player
Not Installed

Apple Developer Tools
Xcode 7.1 (9079)
Build 7B91b

Xamarin.iOS
Version: 9.1.0.27 (Business Edition)
Hash: 1f068b4
Branch: master
Build date: 2015-10-27 18:59:21-0400

Xamarin.Mac
Not Installed

Build Information
Release ID: 509080000
Git revision: cc5f6e5658589ca7f46210c57fad947e75f30abd
Build date: 2015-10-21 19:27:41-04
Xamarin addins: d77f191bd7d3451adf837b85b38f2b7c60004400

Operating System
Mac OS X 10.10.5
Darwin blushweaver.amer.corp.natinst.com 14.5.0 Darwin Kernel Version 14.5.0
    Wed Jul 29 02:26:53 PDT 2015
    root:xnu-2782.40.9~1/RELEASE_X86_64 x86_64
Comment 1 Randall Schmidt 2016-01-15 16:47:34 UTC
Created attachment 14602 [details]
Screenshot of issue occurring
Comment 2 Randall Schmidt 2016-01-15 16:48:03 UTC
Created attachment 14603 [details]
iPad settings at time of occurance
Comment 3 Sebastien Pouliot 2016-01-15 20:46:17 UTC
Initialization of the CultureInfo can be tricky as it's not possible to perfectly match iOS/OSX and .NET cultures information as their design differs.

iOS sees cultures as a language and a region, both distinct, e.g. en-DE is fine because both 'en' and 'DE' exists, while .NET see this as a single item (en-DE is not valid).

The mono runtime (see mono/metadata/locales.c) initialize the CultureInfo using CFLocaleCopyCurrent and then query the kCFLocaleLanguageCode and kCFLocaleCountryCode. It will fallback to use CFLocaleGetIdentifier if the first values did not produce a match.

Those API _should_ return the same values as iOS settings shows, if not then it the resulting CultureInfo will not match (partially or globally) what you expect.

Can you get the output of those API on the devices that shows the problem ?


Note: Xamarin.iOS will also query `NSLocale.CurrentLocale` to set the default .NET RegionInfo to match the same country code. But that does not sounds like it's the issue you're seeing.
Comment 4 Randall Schmidt 2016-01-15 21:22:29 UTC
Thanks for the response Sebastien.

I discovered the problem. Under "Region Formats" in settings, there is an "Advanced" row. In there, there is a setting for language which is separate from the overall language setting, and that was set to Bulgarian. This setting apparently should only apply to "dates, times, and numbers" :)

But this is apparently the setting that Xamarin uses for setting the CultureInfo. Is that a bug or is there some reason why it should be that way?

The output with CFLocale:

print(CFLocaleGetValue(CFLocaleCopyCurrent(), kCFLocaleLanguageCode));
   = bg
print(CFLocaleGetValue(CFLocaleCopyCurrent(), kCFLocaleCountryCode));
   = DE
print(CFLocaleGetIdentifier(CFLocaleCopyCurrent()));
   = bg_DE
Comment 5 Sebastien Pouliot 2016-01-20 19:17:21 UTC
> This setting apparently should only apply to "dates, times, and numbers" 

A bit confusing, the recent (iOS) UI text says (at least in French) that it's used for dates, times, and numbers but it does not say it's _only_ used for them. However changing this value does not change iOS UI language.

That make it sounds like it should be used for `CurrentCulture` but not for `CurrentUICulture` even if it's not really what the API / constant is documented to do [1]. 

I'll have a look for the API that would return us the UI culture.


[1] kCFLocaleLanguageCode

Specifies the locale language code.

The corresponding value is a CFString containing an ISO 639-x/IETF BCP 47 language identifier, such as “ja”.

Available in iOS 2.0 and later.

https://developer.apple.com/library/ios/documentation/CoreFoundation/Reference/CFLocaleRef/

Note You need to log in before you can comment on or make changes to this bug.