[RESOLVED] Different cultures

[mickey_pt]

Hello

I have a little problem, i have one application where workers write the times that they spent doing some tasks, the computers they use have the culture pt-PT. After this the supervisor has to validate the values and send them to SAP, his machine has the culture en-US, and the SAP expect the values in a pre-defined format, right now it's like of the en-US, and i think this will not change. In the beginning when everyone was using the same culture, the application worked just fine, but right now, it isn't...

So what i need it's some advices to change the application in a way that in the future i don't have any problems with the cultures of the machines where my application will be used.

Just set the culture of my application to invariant? Set to some specific culture? Set the culture to the user culture? What are the recommendations?

*EDIT* - BTW the database it's in the SQL Server en-US, but the company it's updating the license and will install a new version and i don't know what culture it will have.

Thanks

[stlaural]

I guess the problem you are having is with the time entries? What we did here is we used the invariant culture and we forced the use of the period as the decimal separator. So when ever someone enters a comma we replace it by a seperator.

I think your could also use the Decimal.Parse method. This way you let the user enter their time as string and when you need to save the data you use the Parse method and you pass it the user's culture as a parameter. This way, whatever culture the database is using, once your values are all parsed in decimal objects the insertion should work.

[dbasnett]

Why not store the data as numbers, and show it in the culture of the users machine?

[mickey_pt]

Hehehe, no the problem in fact it's with the decimal values, i have to store the task duration in a decimal value, usually the decimal separator it's "," in my culture PT, but in US it's a ".", and for the group symbol it's a " " (space) and "," respectively... So when someone writes 1,5 it may become 1,500 (PT -> US)...

So I'm checking the best possibilities to solve this and I'm trying to avoid InvariantCulture, because this way i need to force the users to write the numbers in a different manner than the way that they used to.

[SJWhiteley]

Parsing the numbers (.Parse and .TryParse) will work fine as long as they - the user - type numeric values in the culture of the machine. The parsing uses the current culture. You won't need to 'force' your users to type in anything other than their own culture.

The question seems to be on the 'storage'. numbers are numbers - formatting is irrelevant. Likewise a date is a date, regardless of culture. However, it sounds like you are storing the numbers as strings. In which case, you will have to use a known culture to store and read the value. The correct solution is, of course, to correct the storage mechanism if you are indeed storing the values as strings.

[mickey_pt]

Yes and no, yes that in fact I'm converting the numbers to string, but i only do this because the webservice that i need to use to connect to SAP, only accept strings, and at this point i need to verify that i'm sending the correct values.

After writing and thinking and reading some of the comments, what I'll do it's let the application stay in the current culture of the machine (do nothing to the code), and only the last step I'll do a replace of the separators if the culture separators are different for the ones that i need to use the webservice and send the correct values.

Thanks

[stlaural]

Don't you think that it could be a pain to replace the characters? Parse() already makes sure that the values entered can be paresed to Decimal and it won't work if the user entered invalid data so it does part of your validation. Once you get the decimals, the supervisor(s) can view the data in their own culture and the same decimals can then be converted to strings, with the proper culture for SAP, and be sent to the webservice.

Replacing values (separators etc..) in your code could still fail if the user entered invalid data. If you chose to go that way it might need to be pretty robust.

[mickey_pt]

Thanks for the tips, but the user can't insert invalid values, because the application doesn't allow it.

Like i wrote it looks like the SAP has the en-US culture but i don't have 100% sure and the web service it's expecting strings, so my only option it's using a simple code to replace the separator char after calling the toString method for the decimal value...

[stlaural]

Oh ok I see, you are converting to string while you are still using the pt-PT culture? so that's why you need to manipulate the resulting string. Still, instead of manipulating the string, you could simply find the SAP culture and use it when you call the decimal.ToString() method. Anyway, I thinks those are the two only available solutions Simple things can get so complicated sometimes.

[mickey_pt]

Yes i know, but like i said i don't have 100% sure of the culture...

Thanks to all