Support both `.` and `,` as decimal separator when entering numbers

[ThiefMaster]

Problem Statement The Windows 7 calculator allowed users to enter both . and , as the decimal separator. This is very convenient because while certain locales uses , (e.g. German) as the decimal separator, it's still very common on websites, applications, etc. to use the . separator. Supporting both allows for flexibility when entering values.

Evidence or User Insights The calculator in Windows 7 supported this.

Proposal The calculator should accept both . and , as a decimal separator.

Goals User can enter both . and , as a decimal separator

---

The only tricky point I see here is how pasting numbers should be handled:

• If the separator appears multiple times it's probably safe to assume that it's a thousands separator and not a decimal separator.
• If multiple separators appear, then the last one should probably be considered the decimal separator; if that one occurs multiple times as well, best to reject the paste since it's not clear what the number is supposed to be
• If exactly one separator is present, it's ambiguous what it should mean. The Win7 behavior here is to only allow the separator of the current locale when pasting, and treating the other one as a thousands separator that should be ignored.

[MicrosoftIssueBot]

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.

[aaaxx]

For ambiguous cases, marking them and offering the user some kind of UI to point out the right character or place a new one would be much more user friendly than rejecting the input.

Also, all Unicode spaces should probably be treated as digit grouping character (i.e., silently dropped), whether pasting or typing the number.

[KillyMXI]

In the discussion of PR #145 some ambiguities were shown. I have written a similar format interpretation logic there before I found this ticket. I wonder if it's a good idea to copy it here.

Update: that PR was just locked to comply with contribution process. I'm waiting to see which issue will be used for discussion.

[grochocki]

@ThiefMaster Thanks for submitting your idea! We agree there is likely something we can do to improve this experience, but it would be good to refine the idea a bit more before moving forward.

The Windows 7 calculator allowed users to enter both . and , as the decimal separator... Supporting both allows for flexibility when entering values.

We agree that regardless to your PC's language settings, we should be able to handle pasted input with both separators. Is this what you had in mind? Or would you expect the ability for a user to type input with physical or in-app keyboard to do the same? In general, we want to respect the system settings for direct input. If you prefer one style over the other, you can change this in your language settings.

If exactly one separator is present, it's ambiguous what it should mean. The Win7 behavior here is to only allow the separator of the current locale when pasting, and treating the other one as a thousands separator that should be ignored.

I agree this can be tricky, and maybe we can figure out the details later, but can you clarify what you mean in this case? For example, what would you expect if I pasted "123.456"

For ambiguous cases, marking them and offering the user some kind of UI to point out the right character or place a new one would be much more user friendly than rejecting the input.

We worry that this might easily become too complex, and in general, we want to avoid blocking UI like popups. Ideally, we can handle all scenarios more fluidly without requiring additional user action.

@KillyMXI We should use this issue to track improvements to this, so let's keep the conversation here until we figure out how to tackle this.

[ThiefMaster]

Or would you expect the ability for a user to type input with physical or in-app keyboard to do the same?

Yes, that's indeed what I had in mind. Like I said, on Windows 7's calc this worked just fine. I think most apps just use the system setting for output (well to be honest, many completely ignore them) but follow the principle of "be lenient in what you accept for input, but be strict of what you output".

[I-Campbell]

General conference on weights and measures say: Decimal place can be either '.' or ',' Thousands and Thousandths separator can be a thin space. '.' nor ',' should not be used as thousands nor thousandths separators to avoid confusion.

So I think it is reasonable that:

1. If only one occurance of only one separator then this is treated as a decimal place.
2. If two occurances of one separator exist and only 1 or none of the other separator, treat the repeated separator as a thousandths or thousands separator.
3. If one each of two different separators are present, use the local language settings to figure out which is the decimal separator.
4. If two occurunces of both separators exist ( ie. an erroneous entry) remove all separators and let the user correct.

Examples: 10,000: ten 10.000: ten 10,000.00: ten thousand in Australia, ten in Germany. 10.000,00: ten in Australia, ten thousand in Germany. 10,000.000,00: ten thousand 10.000,000.00: ten thousand 10.000.000,000,000: ten trillion (ignore all separators)

I think this should be the same for pasted input or typed input.

Any calc documentation on numerical entry should point out the importance of numerical unambiguity across cultures, and they should be using , or . for decimal place and either a thin space or nothing at all as both a thousandth or thousands separator.

[ThiefMaster]

Since I just got reminded of this issue thanks to the (very interesting!) comment, another idea regarding this came to my mind:

Or would you expect the ability for a user to type input with physical or in-app keyboard to do the same?

If you type a number, chances are good that you will never enter thousands separators. So I think for that case it makes sense to accept both . and , as the decimal separator (and reject any repeated input of either of those chars once one has been used).

[HowardWolosky]

If you type a number, chances are good that you will never enter thousands separators.

Unless you're copying and pasting a number from somewhere else that was formatted that way....

[ThiefMaster]

Sure, but it's easy to detect whether it's copy&paste or actual typing.

[I-Campbell]

@ThiefMaster: I agree. That also complies with Weights and Measures, so I like your one better for typing. You can expect the user to copy/paste text written by non-compliant authors though, in which case my disambiguation cases should be used.

@HowardWolosky: copy paste and typing are different code areas.

[miloush]

@I-Campbell what is the standard you are suggesting compliance to, and how is it better for end users than CLDR?

[I-Campbell]

@miloush:

https://www.bipm.org/en/CGPM/db/22/10/

These guys do the SI units.

CLDR is for what the user is likely to enter, but fails to recognise that the user is a global citizen and may be copy pasting from a website from another country.

[miloush]

@I-Campbell Thanks.

Some of the behavior you propose is breaking (i.e. changes what the calculator, both Win32 and UWP, currently does for the same input). I would argue global citizen should have their preferences respected, and I would be cautious about re-interpreting pasted values, especially in unit conversion where it can create confusion. Don't also forget that currently there is no way for user to edit entered numbers.

This issue seems to propose both the dot and comma keys to be treated as a decimal separator, the same way Win32 calculator does it, which would on its own be a significant improvement. The discussion seems to have been focusing on resolving ambiguities, but the calculator already supports pasting values, for both "10,000" and "10.000", so perhaps if users are unsatisfied with how that currently works, a new issue should be opened.

Don't forget that user can set the decimal and grouping separator to be the same character, and/or more than one character (the UWP uses the first character only though, unlike Win32).

[thomaslevesque]

A compromise could be to make the new behavior optional. Personally, I never use the thousands separator when typing a number, and it's rarely present in numbers I try to copy/paste, so I'd like to interpret '.' as the decimal separator, even though in my locale (French) the standard separator is ','.

[jgleal]

I think nobody uses thousands separator when write a number... Isn't more logicall respect the decimal separator of language configuration and ignore thousands separator?

[thomaslevesque]

Isn't more logicall respect the decimal separator of language configuration

More logical, maybe, but not necessarily more convenient. The decimal separator in my language is ',', but as a programmer I'm used to use '.'. So I'd like to be able to use either.

[ghost]

This pitch looks like it has everything it needs for review. In the meantime, we'll keep this idea open for discussion so the community has the chance to provide feedback. Check out our New Feedback Process for more info on the user-centered process we follow for new feature development.

[0x49D1]

I just can't copy numbers from calculator anymore: 10,023,100 is NOT treated as 10023100! Why on earth should I copy the FORMATTED numbers? The main problem is with the websites who check if the pasted value is ASCII characters and they just fail after I paste "," and "save the memory about my pasted values" until I hide the input field (Hello AWS S3 headers parameter section!). Can we just COPY the number from calculator WITHOUT grouping commas? I really don't even want such "grouping", but there is no option to disable that feature.

[grochocki]

Thank you to everyone for the great discussion on this issue. We had the chance to review the idea more closely, and we feel like we need more information before deciding whether to continue.

First, the support we have today for accepting pasted values when they are formatted to align with your system settings has one key benefit--it is consistent and predictable with how numbers are represented throughout the rest of the system.

That being said, we definitely understand the user pain point this change is seeking to address. We are generally supportive of this pitch, as long as we can consistently and predictably handle pasted input regardless to what your region's thousands and decimal separators may be (comma, period, space, etc.)

The ambiguous cases are the problem. Is "100,000" "one hundred" or "one hundred thousand"? Thanks to folks who have proposed rules above, but we don't think we've landed on a good set of rules here. Unlike #162, where there is only a possible loss of precision, making the wrong assumption here can result in huge swings in order of magnitude. We cannot think of a good way to confidently determine one way or another, so we would like to keep this idea and discussion alive and take another look once we have clearer set of rules we can follow.

[I-Campbell]

I think, at least for the first ambiguous paste you will have to interrupt the user. "Hi, we don't like to make assumptions! It is possible you have pasted values from one of these sources:

• Weights and Measures compliant numbers
• Your own regional number format
• Someone else's regional number format As programmers, we would love everyone to use Weights and Measures compliant numbers because it translates so well across cultures. However we know how important tradition is to ones culture, so we want to give you some options: ( ) Assume weights and measures in the first instance, else ask me every time. [We won't be as intrusive as this message, we promise] (Default) Assume weights and measures in the first instance, else assume my traditional regional format. ( ) Assume my traditional regional format in the first instance, else assume weights and measures. ( ) Assume someone else's regional format, all the numbers I deal with are from somewhere else in this world! ( ) Ask me every time the paste is ambiguous. If you change your mind, you can update your preferences at any time." If this feels too much like an anthropomorphic paper clip, maybe don't ask, just set the default, document the feature and let the user change it in options. Maybe in this case, the default is displaying "invalid input" for ambiguous values, with a shortcut to the position in options where they can choose another. "Ask everytime" could be realised as three radio buttons that appear where the number would have been when you paste a number. Grey out any option that is not possible.

[0x49D1]

The ambiguous cases are the problem. Is "100,000" "one hundred" or "one hundred thousand"? Thanks to folks who have proposed rules above, but we don't think we've landed on a good set of rules here. Unlike #162, where there is only a possible loss of precision, making the wrong assumption here can result in huge swings in order of magnitude. We cannot think of a good way to confidently determine one way or another, so we would like to keep this idea and discussion alive and take another look once we have clearer set of rules we can follow.

Let me explain more. The real problem in my case was is not even 100,000 or 100.00 or 100000: many web services accept only integers (almost all, even in HTML standard number field there is clear INT), and not when I do select all and then copy & paste into the number input - it pastes with 100,000 so that the field validation fails. I always have to remove the ','. How is this connected to the way I set the localization/culture settings on my PC? That settings are just representation, the default must be determined by the service where I paste the number in some standard notation (as I know the standard pure number with '.' as decimal separator). Sure I'm not an expert in the question, but the updated calculator made paste experience for me just painful. The old version without additional cultural formatting was way better (probably not just for me).

[ThiefMaster]

Yeah I think copying should strip anything except the decimal point, and pasting should try to be smart - if there's only one way to parse use that, otherwise prompt the user.

And when typing... well, nobody types thousands separators, so both .. and , should be a decimal point then (and typing more than one should of course be disallowed).

[KillyMXI]

@0x49D1 you talk about different issue from what is discussed here, I believe. For issues with copying FROM Calculator you better open a separate issue. That will be more effective.

[KillyMXI]

I can see the appeal of a configuration-free and dialog-free application in the smartphone era. But it also puts irresolvable constrains, making the app the least useful for the real world. Some level of flexibility is important to be able to integrate into workflows involving different systems developed with different mindsets... As a developer, mainly working with data in culture-invariant format, but having different regional format, the current Calculator logic totally fails the reality check and rendered useless most of the times for me.

I was going to refine my parser logic suggestion before posting it here. But it looks like more fundamental roadblock have to be moved first.

My suggestion is to add alternative paste command and alternative parser. Also refine existing parsers for all modes while at it.

• Ctrl+V - Paste - uses the basic parser, very picky for the formatting;
• Ctrl+Shift+V - Smart Paste - tries to make sense of input and asks for user choice dialog on ambiguous inputs (shows both interpretations, asks to choose one).

All parsers:

• Standard
• Standard smart
• Scientific (also accept exponential notation 1.23E+03)
• Scientific smart
• Programmer (also accept stuff like 0xFF)

Fall-through rules (inspired by comments in #162):

• If paste into Standard mode and current parser failed - try Scientific parser, then Programmer parses. If any of them succeeded - switch to that mode.
• Same with Standard smart -> Scientific smart -> Programmer.
• Same with Scientific [smart] -> Programmer.
• Same with Programmer -> Scientific smart.

This way, the main track will remain consistent and dialog-free. But there will be a flexible alternative to deal with real world scenarios.

I also have to note that "consistent" is not "error-free". I still have to pay attention, or Calculator will ignore the decimal separator when I paste 1.2 for example. That's why I would rather have a side track that I consciously choose to have all ambiguities captured and confirmed.

[thomaslevesque]

I like @KillyMXI's suggestion.

Another way of handling this would be to show a hint on paste, like in Word:

For instance, if the user pastes "100.000", parse it as 100.0, but show a hint saying "Did you mean 100 000" or something similar. Of course there would be a bit of UX work to make it nice and easy to use.

[I-Campbell]

@Thomaslevesque I love the paste options dialogue idea. Everyone is familiar with that functionality. It also doubles as a known keyboard shortcut, as everyone knows from word that you can press Ctrl+V, Ctrl, and then a key for each of the options. M for Mine, E for Europe, A for America, S for Standards? Can I request Standards is default paste, or is that too rude?

[leduyquang753]

I think there should be an option to opt for the dot to be the multiplication sign instead, as some countries like Vietnam use it like so.

[miloush]

@leduyquang753 this doesn't look like a source you can select text from and paste into the calculator, and even if you have a formatted text, it will be most likely pasted as 2.10-7 so you have other issues to solve first. Do you have an example where the dot is used for multiplication but not by powers of ten?

[leduyquang753]

@leduyquang753 this doesn't look like a source you can select text from and paste into the calculator, and even if you have a formatted text, it will be most likely pasted as 2.10-7 so you have other issues to solve first. Do you have an example where the dot is used for multiplication but not by powers of ten?

It is right in the shot above:

[KillyMXI]

@miloush @leduyquang753 this better be discussed in the linked issue. https://github.com/microsoft/calculator/issues/1251

For the current issue, it's sufficient to mention that in some cultures full stop can even be not a separator but a mathematical operation.