I'm having trouble in my app managing one Culture used for data and one used for user-interaction. For data I want the Culture to always be English, as that's how I'm specifying my dates, prices, etc and how I need them to be parsed. However when displaying strings to the user those should be shown formatted correctly for the user's Culture.
Currently I'm not specifying a Culture so typically everything is processed using the user's Culture by default. I then fix the problems as they arise on an ad-hoc basis, but this is not ideal. I need a more systemic approach. Is there a way to specify the culture that should always be used on a class by class basis? Or some other way to manage cultures better than what I'm currently doing?
Related
Hi guys my problem is this. I made a software in c# that is able to read and edit dxf files, I have to give this software to an american company but I have discovered the following problem:
Where I live we use the ',' to separate the integer part from the decimal part of the number (for example: 2,3658) but in the USA they use the '.' so they write 2.3658.
When I try to read the string "2.3658" and convert it into a double with "Double.Parse("2.3658")" the double I get is 23658 like the method "Parse()" didn't recognised the decimal part.
I have found the following solution:
UpdatedCoorx = double.Parse(shiftedE[w + 1] ,NumberStyles.Number,CultureInfo.CreateSpecificCulture ("en-US"));
Using CultureInfo.CreateSpecificCulture ("en-US") the c# can read the numbers correctly.
My question is : is there a way that make c# automatically recognised the "Culture" of the pc where is installed so that it can read the number correctly???
is there a way that make c# automatically recognised the "Culture" of the pc where is installed so that it can read the number correctly?
That's what it's doing by default - and why you're having a problem, because the culture used to created of the value you're parsing ("2.3658") isn't the culture on your local machine.
For any particular value, you should really know which culture produced it. For machine-to-machine communication, it's best to use the invariant culture (CultureInfo.Invariant) which is mostly similar to the US. Ideally, you shouldn't store values in a culture-specific format at all; either store them in a binary representation instead of a string, or if you must store a string, treat that as effectively machine-to-machine communication.
If you're in the unfortunate position of receiving data where you know it's been formatted according to some human culture, but you don't know which one, you should probably use some heuristics to detect what the culture is. That can easily fail though - for example, is "1,234" meant to be a 1 followed by a "grouping" separator, followed by 234 - meaning one thousand, two hundred and thirty-four... or is it meant to be a 1 followed by a decimal separator, making the value just a bit more than 1? Both interpretations are valid, depending on the culture you use...
If you want to detect the Culture, you should be able to do so with this
As explained in the link CultureInfo.CurrentCulture returns the Culture from the Windows GetUserDefaultLocaleName function.
Jon's answer is pretty spot on (as usual). I just wanted to add that if you are developing an application that will be used by people in another country, it may be helpful for you to use CultureInfo.DefaultThreadCurrentUICulture while you are in development mode: just assign your users' culture to this property when the application starts, and you will have exactly the same usage experience (culture-related-things-wise) that your users will have. (Just remember to remove this when you ship your application! You could for example use a #if debug block)
Do region and language selections in the Windows OS actually have a set of characters associated to them?
When you use the CultureAndRegionalInfoBuilder class to register a new culture to the system, the only characters associated to your new culture that you can set are the native digits. I need to register an obscure language that uses UTF-8 characters that don't exist in the languages that come packaged with Windows or in any of the language packs. I'm uncertain about the internals of Windows culture definitions and whether or not a character set is stored with them. My assumption is that the culture definition does nothing more than let you specify the native digits and various formats used in that culture and give applications a mechanism for localization and formatting and that it really has nothing to do with a specified character set. Can someone tell me if my assumption here is correct.
Your assumption is correct; the custom culture created by CultureAndRegionalInfoBuilder does not define a set of characters used by the language.
Out of curiosity, what language do you want to support?
I have a couple of tables with Spanish, Japan, French and other languages for my site. I don’t want to use Resource file cause it will take a lot of time to manually change. So I can take the current thread, take what culture you are using and if its lets say Italian to execute the query which retrieves the resource from the appropriate table. Is it possible to localization values from code behind instead of a resource files? A seperate resource file would mean we have to update (a lot of) translations in different locations (and with different tools) which is not good.
We used database based approach similar to the one you described in a large ASP.NET web application with several supported languages.
In fact we did not change the Thread Culture, we had a login screen where the user could select the language and based on that selection we had an helper class which "knew" the current language and always retrieved to us values in that language.
as per changing values from code behind we had in all web forms (hundreds of them) a method called initUITexts which simply did something like the following:
label1.Text = LanguageHelper.GetText("PageName.label1.Text");
label2.Text = LanguageHelper.GetText("PageName.label2.Text");
button1.Text = LanguageHelper.GetText("PageName.button1.Text");
it is probably not the best or the only way but it worked fine for us and all logic of querying is encapsulated inside LanguageHelper.
I'm working on a desktop application that may potentially be deployed world-wide. My biggest issue with internationalization is currencies. A couple questions:
I'm using SQL Server Compact Edition, which supports the MONEY type. My first question is will this handle data storage regardless of the user's culture?
My second question is data processing. I know I can use the "C" format string, and I guess that's all right for displaying, but when saving back how do I handle user-entered values? Is there a standard way to parse the entered value and save it to the MONEY field, all while being culture-aware and not having to write for any kind of exceptions?
I'm working with C# in WPF, but I'm guessing there is probably a near-universal solution to all this.
The MONEY type just tells the system to use the required accuracy and rounding rules required to handle monetary calculations properly. It doesn't know anything about the actual currency. You need to handle that in the UI and with currency conversion rules.
The framework uses the current culture to display the correct currency symbol for monetary string formats, but if you are displaying different currencies you'll need to override this behaviour.
With C#/WPF (and Silverlight) if you output the currency using the StringFormat in XAML then it handles the user input as well (or at least it has in my experience).
The question might sound weird, but I am planning to create a asp.net website, which when fully done, will ideally cater to all countries.
I am currently in the architecture phase.. and is there anything that I should keep in might when doing this?
like
saving all datetime fields in utc
using user's timezone to display all time related data
all labels in the website to be localizable
is there anything else??
thanks,
Chris
A few additional points:
Some languages read from Right to
Left (Hebrew for example), which
will affect your UI.
Make sure your datastore supports
unicode (NVARHCAR vs VARCHAR).
Provide an easy way for translators
to contribute content. Usually means
creating a Data Driven Resource
Provider.
Internationalization and Localization is a good place to start.
You should think about how the localization process will take place. I assume you are not a native speaker in all languages you want to use for your application.
There are several approachs on how to address this: For example, there are companies that specialize in localization, meaning you give them an excel sheet, or an xml file.
You should also think about, where do you want to have all these localizations. Do you only want them in your ASP.net application, meaning in only one place? Then the resource file will be your way to go, because they are easy to handle and easy to send to localization studios.
But if you want to use the localizations in more than one place, you need to store them in a web service or in a database. Keep in mind that using localizations across multiple plattforms (e.g. web site, administrative tools) will force you to write import/export functionality for the used tables. (Because you won't give the localization company access to your database)
I would start by looking here: http://msdn.microsoft.com/en-us/library/c6zyy3s9.aspx.
I also guess you are working on doing a SQL database. If that is the case look at things like using nvarchars.