4

I have written a user control which is not compatible with cultures other than "en-US". Also it is inevitable to embed this user control in an application with a culture which is not "en-US". So is it possible to force the application to not to change this user control's culture?
Its preferable to have a solution inside the user control.
I have read this thread : Localizing a WinForms Application with Embedded WPF User Controls but I can not use WpfLocalization.LocalizationScope.SetCulture
Does this function really exists ?

And also there is a Localizable tag which can be set to False but It is just for resource definitions in .csproj files: http://msdn.microsoft.com/en-us/library/ms788718.aspx

So is there anybody who has any idea about this problem ?

More clarification :
Suppose we have an application with culture X and a user control which is compatible with culture "en-US". This user control has a dependency property which is of DateTime type and it is getting its value by this way : 
<my:uc1 x:Name="UserControl1" Date="4234/12/22" />

When application culture is "en-US" user control will get "4234/12/22" but when the application culture is something else, it converts "4234/12/22" automatically to the application's own calendar and delivers "0744/04/08" to the user control and ruins every logic behind the user control ! It's completely a disaster.

I want to prevent this conversion by setting the user control's culture exclusively to "en-US".

Hope that I have clarified the situation enough.

Community
  • 1
  • 1
Spongebob Comrade
  • 1,495
  • 2
  • 17
  • 32
  • Besides the surprising date you want to use (which by the way isn't represented in "en-US" format which is `M/d/yyyy`) which culture converts it to "0744/04/08" (even more surprising)? – Martin Liversage Apr 30 '12 at 09:27
  • @Martin Liversage: It's just an example. Let me keep that culture clandestine :-& – Spongebob Comrade Apr 30 '12 at 09:40
  • Sorry if I disclose any secret, but given the huge year I'd say Hebraic calendar... More seriously, this thread is really interesting to me as I'll probably have to manage soon dual-culture (French/Arabic language or Gregorian/Ethiopian calendar) oddities. – odalet Oct 23 '13 at 13:58

1 Answers1

5

You can set the FrameworkElement.Language property of your control or apply the xml:lang attribute to the XAML of your control. The value you have to set is en-US.

The culture you set using this property/attribute affects how culture-specific strings are converted in the control. E.g. if you display a DateTime using the D (long date) format you get something like Monday, 30 April 2012 when xml:lang="en-US" and 30. april 2012 when xml:lang="da-DK".

However, if you specify a date in XAML like in

<my:uc1 x:Name="UserControl1" Date="4/30/2012" />

that date is parsed using CultureInfo.InvariantCulture (basically en-US). That is not the behavior you seem to describe. You are a bit vague in the description of you real problem but to verify my claim you can try to enter 30/4/2012 for the date and see that it fails to compile. It does that not only when the current culture of Visual Studio is en-US but also as it is in my case da-DK (where the date format is d/M/yyyy).

Martin Liversage
  • 104,481
  • 22
  • 209
  • 256
  • Thanks for your consideration but it doesn't affect the user control culture which is still non "en-US". I have checked culture in user control load but it is still the same as past. – Spongebob Comrade Apr 30 '12 at 08:06
  • @SarahCompard: Can you clarify the meaning of _user control culture_ in your comment? If you set the `xml:lang` attribute in XAML then string formatting in bindings will use the appropriate `CultureInfo` etc. Where exactly in your user control are you having localization problems? – Martin Liversage Apr 30 '12 at 08:34
  • I have provided more details in the question. Thanks for your attention. – Spongebob Comrade Apr 30 '12 at 09:20
  • Thank you very very much. The point was in CultureInfo.InvariantCulture. I didn't know anything about it. I temporary set thread culture to it and do my job then return back the culture to its previous culture. It was impossible with other cultures. You finished my nightmares which was lasted for fortnight!!! – Spongebob Comrade May 01 '12 at 12:07
  • I've set all these to my hr-HR and controls still format numbers in en-US. These same settings work in another project: Thread.CurrentThread.CurrentUICulture ; CultureInfo.DefaultThreadCurrentCulture; CultureInfo.DefaultThreadCurrentUICulture ; CultureInfo.CurrentCulture; CultureInfo.CurrentUICulture; System.Windows.Forms.Application.CurrentCulture ; – Hrvoje Batrnek Aug 09 '19 at 17:59