microsoft
PT-Run calculator: disable number formats for the input
Description of the new feature / enhancement
Add a toggle to disable number formatting requirement for the input, so we would use numbers like 123,456.78 and 123 456,78 - note that period and comma in the decimal part are interchangeable.
Scenario when this would be used?
I am one of those people who have both English and Russian keyboard layouts with English regional formats. As such, when I am inputting numbers from the numpad it is coin toss if I am going to input "123.45" or "123,45" - English and Russian float formatting respectively. This is where the proposed feature comes in, providing user with a toggle to disable formatting to treat both "2.5" and "2,5" as "two and a half", rather than "two and a half" and "twenty five".
Supporting information
Related, but old with no solution: #12121 #13562 #25285
Update: I started debugging and it looks like the problem lies in the NumberTranslator class that (as used here) formats the numbers to confirm with the chosen locale, and not just CalculateEngine as I first thought - so my test number 123.4567,89 reads as 123.456789 right after var input is created in main.cs. I am actually not sure how to fix it without turning off the "translate to locale" system for the calculator module, which I presume is there for a reason.
@evinnichenko There is a plugin setting to choose if you need English or regional input format. (PT Settings > PowerToys Run > Plugins > Calculator plugin > Expand plugin settings)
(Supporting both at the same time is a problem as we don't know if the user means decimal separation or thousand separation.)
@htcfreek, that's exactly the problem though. The setting you are talking about overrides local number formatting, forcing en-US (that is, demanding 123,456.789 instead of e.g. 123 456,789). My computer already has en-US number formatting set, so all numbers read with , as thousand separator and . as decimal separator, irrespective of the layout. Problem is, in RU layout . is bound to different key (.> in ANSI, /? in Russian, comma also moves from ,< to Shift + /?) and numpad's . sends a , instead, so with or without that setting typing a decimal using muscle memory with wrong language turned on would result in bad number format and calculator failing. My suggestion was to give user another option, direct opposite of the one you are talking about, to ignore the formatting at all and make use of the fact that Mages apparently can read numbers without thousand separators. Probably done by changing input in Main.cs around line 99, along with other flag-dependent actions and before it gets sent to Mages.
Speaking of, do you know where I can find a) how to properly set an option flag (couldn't find the locale files to enter my own description and could use a formal process for doing it) and b) how to fix a chain of "failed to load XXX.dll" alert windows on debug startup from VS?
Writing in hope that someone would notice this comment. I did some work and managed to kind of implement it by removing all non-digit characters in the given token and replacing the last of them with a locale-appropriate decimal separator. Problem is, due to how Microsoft.PowerToys.Run.Plugin.Calculator/NumberTranslator.cs/GetSplitRegex() works, it only works on the already-existing decimal and group separators - so it is pure luck that for my specific pair of locales (en-US and ru-RU), the decimal separator of second locale (',') is same as group separator of the first, and so this modification works for me.
Question: how to fix this to work across all locales, irrespective of the language pairs? I am kind of afraid to modify GetSplitRegex() to accomodate all locales, since it might affect other users, even with this flag being optional. On the other hand, the default Windows separators are only ,, ., , and ', so it could work for just those. Something like
if(flag)
`var splitPattern = $"((?:\\d|\\.|,| |`)+)"
else
[existing method]
although it would require access to that field as well, so it needs to be passed somewhere...
@evinnichenko Thanks for looking into this. I think if we find a solution to become intelligent, it will be a big quality improvement.
Currently I don't see your question in last comment? Is there something you need to know? Otherwise I suggest you to create/open a draft PR where we all can look at.
The question was as to how to best approach it, in opinion of others, as right now my solution only works for specific pairs (ru-en being one of them), and not all of them like how I hoped it to be. And that's before I found that you can set custom delimiters, so your numbers could look like 1-234\5 = 1,234.5.
Yeah, will open the PR now to just get it out in the wild, even though I don't consider it quite ready yet.
This is closely related to the setting for "use English format" and I'm worried this is still going to be complicated.
Related but opposite. "Use English format" forces you to use en-US number format no matter the locale, while this aims to allow you to use any symbol from any locale, in case you have a second language and use it to type number not in computer's locale.