-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mitigate calculator deceiving behavior #22417
Comments
Yes, this is a complicated situation. There's a setting that deals with the decimal. Actually, the problem here is that the |
@Jay-o-Way , perhaps we should make the "Use English (United States) number format for input" the default, since it seems that's how people expect it? 🤔 |
@jaimecbernardo it's not about the decimal character. The fractional part is converted into a number and the leading zero's get trimmed off. |
/dup #2265 |
Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report! |
Description of the new feature / enhancement
Do not offer a calculator solution when a number in the query doesn't match current locale.
For example, with french regional settings, one is expected to type in
4,017*5863,46
rather than4.017*5863.46
. But for both queries a calculator result is presented... with one dead wrong (screenshots from v0.64.1):With such settings, it would be less prone to bad surprises to not present the first result at all, and maybe offer to fix the query with a result along the lines of
which, when selected, would replace the input and then present the (correct) result.
Scenario when this would be used?
This could avoid errors for anyone using the calculator on any computer where the regional settings are different from what one is used to.
Supporting information
This proposal is directly linked to the regional settings mentioned in #19741. The solutions from there (changing system or PT settings) are simple and correct, and the issue is easily worked around.
The problem is that it's taken me months before discovering this issue since even with the "wrong" decimal symbol results are wrong only in some circumstances (leading zeroes afer the decimal point) and correct in all other cases. That makes thoses cases viciously hard to detect (at least to me) and I probably have used false results without noticing it.
The text was updated successfully, but these errors were encountered: