[CmdPal] Add number separators to calculator results

[debaditya (DebadityaHait)]

Summary of the Pull Request

Adds culture-aware digit grouping to visible Command Palette calculator result titles. Values used for copy, paste, suggestions, history, and reparsing remain raw.

PR Checklist

• Closes: Large numbers separators in Command palette #40203
• Communication: Discussed in the PowerToys contribution thread and acknowledged by a core contributor
• Tests: Added/updated and all pass
• Localization: No new end-user-facing strings
• Dev docs: Not applicable; no developer workflow or API changed
• New binaries: None
• Documentation updated: Not applicable; no user documentation change required

Detailed Description of the Pull Request / Additional comments

Calculator results previously used the same ungrouped string for both the visible title and operational values. This change derives a culture-aware, display-only string while preserving the existing decimal precision. Page and fallback result titles use the grouped string; command text and TextToSuggest remain unformatted.

Tests cover en-US and de-DE grouping and verify that copy and suggestion values remain raw.

Validation Steps Performed

• Built Microsoft.CmdPal.Ext.Calc.UnitTests for x64 Debug with the repository build script
• Verified the new regression test failed against the pre-change implementation, then passed after the change: 2/2 culture cases
• Ran the full calculator test assembly: 375/375 passed
• Built and launched the packaged x64 Windows UI; a raw 500000 query displayed 500,000 while retaining raw 500000 operational text

Windows UI evidence

The raw query 500000 displays the grouped result title 500,000 while retaining raw operational text 500000.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[debaditya (DebadityaHait)]

@microsoft-github-policy-service agree

[Michael Jolley (michaeljolley)]

• Non-3-digit grouping cultures: (e.g. Indian hi-IN, group sep , == list sep , → strict token pattern \d{1,3}(?:[,]\d{3})+). N formatting yields 1,23,45,678, which that pattern won't match, so continuing a calculation from a replaced/= result can misparse. Edge case, but it's newly reachable because the app now emits these grouped strings.
• Test coverage gap: no test for the replace/= continuation path. A small regression test (type a >1000 value, trigger replace-to-search-box, append +1, assert the result) would lock in that the grouped Title round-trips.

[debaditya (DebadityaHait)]

Addressed the review feedback. Calculator continuation now uses the ungrouped operational result while retaining the culture-grouped display title. Added hi-IN regression coverage for both replace-to-search-box and trailing = continuation paths, with both copy and paste primary actions.

Validation: all 451 calculator unit tests pass.

[Michael Jolley (michaeljolley)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Jay (Jay-o-Way)]

[edited/redacted by Jay]

Note that e.g. Chinese, Japanese, Korean, Vietnamese grouping is done in groups of four: 123,456 (Western) = 12,3456 (Chinese)
There are also several different characters being used globally. Make sure everything is correct.

[debaditya (DebadityaHait)]

Thanks for raising this. I double-checked the implementation and it does not hardcode Western three-digit grouping or separator characters. It uses .NET's NumberFormatInfo, so group sizes and separators come directly from the selected locale—for example, Indian 3,2 grouping, spaces, periods, apostrophes, and Arabic commas are handled automatically.

Current .NET locale data uses three-digit separator grouping for zh, ja, ko, and vi, so the PR follows the platform's localized number format rather than maintaining a separate locale table that could drift from Windows/.NET behavior.

I can make this clearer with focused tests covering a four-digit NumberGroupSizes pattern and representative non-comma separators, proving the formatter is not restricted to Western grouping. If there is a specific Windows/.NET formatting API or locale setting you expect for the CJK examples, I'm happy to align with it.

[debaditya (DebadityaHait)]

Michael Jolley (@michaeljolley), when you have a chance, could you confirm whether following .NET's NumberFormatInfo is the expected localization behavior here? If so, I can add focused coverage for four-digit group sizes and representative separator characters.

[Jiří Polášek (jiripolasek)]

I think this should be optional. Enabled by default - fine, but I'd like to turn it off, so I don't have to spend time deleting those separators.

[Dave Rayment (daverayment)]

Woul

I think this should be optional. Enabled by default - fine, but I'd like to turn it off, so I don't have to spend time deleting those separators.

Would it be feasible to have this feature as "display-only", so copying the result only copies the numeric value and not the result string?

I may be mistaken, but I think we may have discussed this on one of the earlier aborted attempts at doing this.

[debaditya (DebadityaHait)]

Yes — that is already the intended behavior in this PR. Digit grouping is display-only; copying or pasting a result uses the ungrouped numeric value, and continued calculations also use that raw value.

[Michael Jolley (michaeljolley)]

Closing this as stale. No activity in a month and it doesn't build.