Bug 6049 - Android-specific Locales are not supported
Summary: Android-specific Locales are not supported
Status: ASSIGNED
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries ()
Version: 4.2.x
Hardware: PC Mac OS
: Normal normal
Target Milestone: master
Assignee: Marek Habersack
URL:
Depends on:
Blocks:
 
Reported: 2012-07-09 13:27 UTC by Jonathan Pryor
Modified: 2017-03-21 20:27 UTC (History)
6 users (show)

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


Attachments
A test program that shows the mono local results on an Android device (17.40 KB, application/octet-stream)
2014-01-10 15:27 UTC, T.J. Purtell
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report for Bug 6049 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
ASSIGNED

Description Jonathan Pryor 2012-07-09 13:27:05 UTC
RegionInfo.CurrentRegion returns null if the device has a locale selected that Mono doesn't have data tables for.

1. On your Android device, click Home > Settings > Language & input > Language
2. Select Bahasa Indonesia (Indonesia)
3. Create an app which contains the following statements:

> 	Console.WriteLine ("CurrentCulture.Name: {0}", System.Threading.Thread.CurrentThread.CurrentCulture.Name);
> 	Console.WriteLine ("CurrentRegion: {0} {1}", RegionInfo.CurrentRegion != null, RegionInfo.CurrentRegion);

Actual output:

> I/mono-stdout( 2811): CurrentCulture.Name: 
> I/mono-stdout( 2811): CurrentRegion: False 

Expected output: Something useful. ;-)


Additional info: Android should probably do something similar to iOS:

https://github.com/mono/mono/blob/master/mcs/class/corlib/System.Globalization/RegionInfo.cs#L53

We should also see what other platform "glue" MONOTOUCH has that Android should also do
Comment 1 Brian G 2012-07-10 13:32:33 UTC
Just adding a note that this bug will affect us in the future when we want to support more cultures. If MonoDroid doesn't support a culture we want to support, we'll have problems.
Comment 2 Atsushi Eno 2012-07-11 05:13:28 UTC
From whatever I can remember, RegionInfo has some specific issue apart from CultureInfo. It does not have "invariant" RegionInfo. It causes some exception if you attempt to create it. Hence supporting non-existent culture can be always problematic when it comes to RegionInfo as there is no way to fallback to somewhere.
Comment 3 T.J. Purtell 2014-01-10 13:25:52 UTC
I am running into a lot of trouble with Globalization currently using 4.10 series.  In particular, I can't change the mono local in response to Configuration Changed event for the locale.  It looks like mono gained support for changing the Default thread culture in November so perhaps Xamarin is working on improving the situation.

I also note that on my US phone, if I select a language like Deutsch.  My Java locale becomes de_US.  Mono does not handle this and so the Culture becomes Invariant culture and their is no available region info.

I would expect there be a more reasonable fallback policy so that the .NET Globalization APIs can be used more reliably.  I'm no localization expert, but does it make sense to just use the de Culture if the specific region version is unavailable?
Comment 4 Jonathan Pryor 2014-01-10 14:45:27 UTC
> It looks like mono gained support
> for changing the Default thread culture in November

It did? What commit is that? (I'm not aware of it.)

Or are you referring to the fix for Bug #15214? That was fixed in 4.10.

Or are you referring to CultureInfo.DefaultThreadCurrentCulture? If so, IIRC that only changes the default Culture for _newly created_ threads. Previously created threads will not have their CurrentCulture changed.

> I also note that on my US phone, if I select a language like Deutsch.  My Java
> locale becomes de_US.  Mono does not handle this

This is: https://bugzilla.xamarin.com/show_bug.cgi?id=1068#c14

> and so the Culture becomes Invariant culture and their is no available region info.

Which is the intent of this bug (Bug #6049): if the default detected culture results in the Invariant culture, we should replace it with a "Java-delegating" CultureInfo instance. Or something.
Comment 5 T.J. Purtell 2014-01-10 15:05:58 UTC
Here is the recent commit I found adding support for Thread default cultures (there are a few more at the same time so there is UI culture and regular culture)
https://github.com/mono/mono/commit/349cb638ff55bab16fe3a8e36176330a30f2dee1 .  I have not tested this out, I just saw it when I was looking for the source of the NotImplementedException's my team encountered.

My understanding of this .NET API is that it affects all other threads which have not set a **specific** UI culture.  So it should affect all threads (since I didn't set a culture explicitly on any thread).  I was looking into this because I was thinking of taking my BaseActivity classes and adding instrumentation to OnConfigurationChanged to update the culture settings (since it is not done automatically ... possibly for good reasons...).

Hmm... from reading the bug #15214, I believe there is some overlap in the difficulties people are encountering.  Note that there are several reports on that bug after it was reported fixed of people still encountering this issue.

I don't have control over the device's region.  That is set by the carrier/phone manufacturer.  In my case, I have a US region set.  I do have control over the language.  So in my case, when I am testing our German translation on my US phone, mono has an Invariant Culture which causes various issues.  Likely it would work on a phone from a German provider.  A German traveling to the US would likely have a US phone that they put their SIM card in (because we have very different bands here), so that user would be stuck in my situation as well.  They would not be able to get a proper locale inside a Xamarin.Android app.
Comment 6 T.J. Purtell 2014-01-10 15:09:45 UTC
In the remarks here:
http://msdn.microsoft.com/en-us/library/system.globalization.cultureinfo.defaultthreadcurrentculture(v=vs.110).aspx

"If you have not explicitly set the culture of any existing threads executing in an application domain, setting the DefaultThreadCurrentCulture property also changes the culture of these threads. However, if these threads execute in another application domain, their culture is defined by the DefaultThreadCurrentCulture property in that application domain or, if no default value is defined, by the default system culture. Because of this, we recommend that you always explicitly set the culture of your main application thread, and not rely on the DefaultThreadCurrentCulture property to define the culture of the main application thread."

The language is a little imprecise, but I think it means: Threads that have not had a culture set explicitly by the developer will have their culture changed automatically when the DefaultThreadCurrentCulture changes.
Comment 7 T.J. Purtell 2014-01-10 15:27:50 UTC
Created attachment 5812 [details]
A test program that shows the mono local results on an Android device

This is the test program we used to root cause the issues we are observing with respect to unsupported Android locales.
Comment 8 Jonathan Pryor 2014-01-10 15:36:01 UTC
https://bugzilla.xamarin.com/show_bug.cgi?id=1068#c15 suggests a way you can workaround the issue yourself: create a new BroadcastReceiver, listen for the ACTION_LOCALE_CHANGED broadcast, and set CultureInfo.DefaultThreadCurrentCulture when you get the event.

You can probably get it working in your app before we can. :-)

The only requirement for you to implement it yourself is that we provide mono/349cb638 (for CultureInfo.DefaultThreadCurrentCulture). Unfortunately, XA 4.10 does not include this fix.

XA 4.12 does.
Comment 9 Jonathan Pryor 2014-01-10 15:36:29 UTC
well, that'll workaround the locale change issue.
Comment 10 T.J. Purtell 2014-01-10 15:40:58 UTC
Yea, I agree with your analysis on bug #1068.  It's not really that important to do it automatically.  I was just investigating this since our testing team was complaining there was unexpected behavior with respect to Android and locale change.  I'll probably just end up nuking the app and restarting to make sure they are testing the real state and not a configuration change workaround.

Incidentally, even major pure Android apps have locale change problem.  For instance, Amazon Kindle just crashes every time I change locale. :)

But yea, the real issue is that the Android locale system has many easy user paths to ending up in a state where Xamarin.Android can't provide good CultureInfo.