2
Vote

Parse configuration values using InvariantCulture

description

I don't see the benefit of allowing culture specific parsing in the configuration. It causes only problems.
 
I don't like the current implementation of the Parse* in the ProviderHelper class because it doesn't use the InvariantCulture when parsing floats for example. If I develop on a machine with WinXP spanish I need to put opacity=",35". However if I deploy to a machine with W2k3 server english this fails because it expects opacity=".35".
 
I think culture specific strings/numbers/dates are useful in UI or string messages but not in configuration settings.

comments

davedev wrote Aug 5, 2008 at 3:40 PM

Thanks for adding this issue.

I'll consider using the invariant culture for the next release, although I'm not sure that I agree at the moment.

The problem with using the system's culture, in your case, is that the production server uses a different culture. A work-around is to use a different web.config for deployment, which is typical of most web apps anyway since most, at the very least, require that debugging be disabled on a production server - by modifying the web.config file. (In VS you can use a Web Deployment Project to help.)

The benefit of using the current culture is mainly for convenience (if deployment isn't a real concern). For example, a text provider can accept a string of characters that are permitted by random selection and then rendered to the UI. Also, numbers and dates can be formatted according to a user's native culture, requiring less knowledge about invariant (English) formatting.

wrote Aug 5, 2008 at 3:40 PM

davedev wrote Aug 5, 2008 at 3:43 PM

Maybe a reasonable solution is to add support for a new attribute on the autoInputProtection element:

invariantCulture="true|false"

It would be false by default.

mabadia wrote Aug 5, 2008 at 4:34 PM

dave, i think the invariantCulture="true|false" will be enough for my needs. thanks

wrote Feb 13, 2013 at 8:30 PM