Should I set Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture by default in my application?

Question

I have an application that is intended for the global market and should be localized. During development, I had some problems related to the fact that my satellite assemblies were never matched, even when I changed my language. After some research, I now understand why this could be verified by setting CurrentUICulture in the code and making sure everything is working properly.

Now it comes to packaging the application for release, and I'm not sure that setting Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture for the current thread when the application starts is a good idea. On the other hand, my application will be localizable by changing the regional settings (if it is at the top), but I am concerned that there may be unforeseen flaws. The one that immediately comes to mind is that, although what I did is good and useful for my stream, it won’t apply (from what I understand, from reading here and around) to any streams, which are created either by my application (except I also install CurrentUICulture on them) or worse than all the components that I use, which can create their own threads.

Could there be other problems? Is setting CurrentCultures the same as standard practice or something that was frowned upon?

I would like you to have so much information about the ups and downs before making a decision.

thanks

Sam

Answer 1

Sam, don't bother with him unless you are really sure what you are doing.

I assume we are talking about WinForms here. The frame raises the optimal settings from the system (as configured by the user). From your question, this might be more of a testing problem. I regularly add code after #if DEBUG to select a locale for testing purposes.

My own example: my locale is Dutch (nl-NL), but I usually run English versions of Windows. If you override CurrentUICulture, I will get the Dutch version (if available), which is usually normal. But I know with certainty that some controls / add-ons will remain in English (including ShowMessage and std Dialogs boxes). The combination is ugly.

But also consider the case when you do not add satellites that match CurrentCulture. The system will revert to the default in your program, while the user interface of the user interface may be the best choice. I don't know all the return rules, but you can probably get something similar to:

The user runs fr-CA settings in fr-FR windows. Your program returns to en-US, user n'est pas happy.

My advice:

• perform some field tests
• if you create an override then use the switch in app.config

Answer 2

Old question, but some user and developer comments:

• I am Norwegian, but for some reason I have an English OS. I hate it when applications appear in Norwegian, because my regional settings are Norwegian.
• I used to use Thread.CurrentThread.CurrentCulture , and although at first it seems that it will work well ... suddenly you have something that works from a new thread ... (spent quite a bit of time figuring out why I got the right one number formatting in my application but not in my reports for example)