Some locales use point symbol to delimit decimal parts of a number and other use comma.
We would love to see both accepted when entering numbers. Currently when we create a new issue with a wrong decimal separator, no error is shown - the issue is saved without estimation and the issue creator can easily miss the problem. That is really inconvenient and leads to problems in the business process.
In short, 0.25 and 0,25 should both be accepted in the estimation field.
Comments: There are two ways to solve this: 1. Change the validatator to properly use the current culture like ``` MinimumValue='<%# (0.1).ToString(System.Globalization.CultureInfo.CurrentCulture) %>' ``` 2. Add the CultureInvariantValues="true" setting to the validator > Culture Invariant Values - When doing conversion on a compare validator's non strongly-typed properties (CompareValidator.ValueToCompare, RangeValidator.MaximumValue, RangeValidator.MinimumValue) the validator will use a culture neutral format (Date: YYYY/MM/DD, Double & Currency: US culture format) to do the conversion when CultureInvariantValues is true. Right now, on the time tracking page the validation uses the CultureInvariantValues="true" setting.
We would love to see both accepted when entering numbers. Currently when we create a new issue with a wrong decimal separator, no error is shown - the issue is saved without estimation and the issue creator can easily miss the problem. That is really inconvenient and leads to problems in the business process.
In short, 0.25 and 0,25 should both be accepted in the estimation field.
Comments: There are two ways to solve this: 1. Change the validatator to properly use the current culture like ``` MinimumValue='<%# (0.1).ToString(System.Globalization.CultureInfo.CurrentCulture) %>' ``` 2. Add the CultureInvariantValues="true" setting to the validator > Culture Invariant Values - When doing conversion on a compare validator's non strongly-typed properties (CompareValidator.ValueToCompare, RangeValidator.MaximumValue, RangeValidator.MinimumValue) the validator will use a culture neutral format (Date: YYYY/MM/DD, Double & Currency: US culture format) to do the conversion when CultureInvariantValues is true. Right now, on the time tracking page the validation uses the CultureInvariantValues="true" setting.