Fix calculator comma decimal parsing

[MardSilva]

Summary of the Pull Request

Fixes Command Palette Calculator handling for comma decimal input such as 1,5+1,5, so it evaluates as 3 instead of treating each value as 15.

Also adds explicit regression coverage for PowerToys Run Calculator inputs without leading zeroes, such as .76*2.4 and -.5*2.

PR Checklist

• Closes: Command Palette Calculator Error when using "," instead of "." #39231
• Closes: Launcher / Calculator should accept floating point numbers without leading zeroes #16287
• Communication: I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected
• Tests: Added/updated and all pass
• Localization: All end-user-facing strings can be localized
• Dev docs: Added/updated
• New binaries: Added on the required places
  • JSON for signing for new binaries
  • WXS for installer for new binaries and localization folder
  • YML for CI pipeline for new test projects
  • YML for signed pipeline
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Command Palette Calculator translated comma-separated numbers using the current culture parsing rules. In cultures where . is the decimal separator and , is the group separator, input like 1,5+1,5 could be interpreted as 15+15, returning 30.

This PR adds a narrow fallback in the CmdPal calculator number translator:

• 1,5+1,5 is translated as 1.5+1.5.
• -1,5+2 is translated as -1.5+2.
• Valid grouped numbers like 1,000+2 continue to be treated as thousands and translate to 1000+2.

This also adds regression tests for PowerToys Run Calculator inputs without leading zeroes:

• .76*2.4
• -.5*2

Validation Steps Performed

• Built CmdPal Calc unit tests:
  • tools\build\build.cmd -Path src\modules\cmdpal\Tests\Microsoft.CmdPal.Ext.Calc.UnitTests
• Ran CmdPal Calc unit tests:
  • 321/321 passed
• Built PowerToys Run Calculator unit tests:
  • tools\build\build.cmd -Path src\modules\launcher\Plugins\Microsoft.PowerToys.Run.Plugin.Calculator.UnitTest
• Ran PowerToys Run Calculator unit tests:
  • 366/366 passed
• Ran build essentials:
  • tools\build\build-essentials.cmd

[daverayment]

Thanks for tackling this. From what I can tell from the code, you have a new NumberTranslator.TryParseCommandDecimal() method which is used when the current culture uses . as the decimal separator, and attempts to reinterpret a comma-separated number token as a decimal number based on the following heuristic:

• One comma only
• Not at the start/end of a token
• Not exactly 3 digits after the comma. These cases are assumed to instead refer to numbers split by a thousands separator like 1,234.

Unfortunately, there are several issues with a solution purely based on string-level heuristics.

The core issue is that commas become inherently ambiguous. They can mean three different things simultaneously:

1. A decimal separator, e.g. 1,5 meaning 1.5
2. A thousands/grouping separator, e.g. 2,000 meaning 2000
3. A function argument separator, e.g. max(2,6)

(Actually, it seems that multi-argument functions are currently broken with comma separators before this PR. It seems that NumberTranslator consumes the comma as a thousands separator before passing on the expression to ExprTK. I'll raise this separately.)

Also, if a number with three digits after a comma is always assumed to have a thousands separator, this means users with . decimal separators cannot type decimals with three digits of precision with the comma - "123,000" is always interpreted as "123000" and never "123.0".

No string-level heuristic can reliably disambiguate these, as it doesn't have knowledge of the entire expression. We could potentially choose a different separator character for functions (; is often used as a separator for precisely this reason in European calculators, for example), but I think that's beyond the scope for this PR.

Without structural changes to how argument and decimal separators are distinguished, I don't think a reliable fix is achievable through string manipulation on its own.