Premium Analytics: format report counts with WordPress locale

[chihsuan]

Fixes WOOA7S-1748

Proposed changes

Report tables were formatting counts with Number.prototype.toLocaleString(), which uses the browser locale. This could make table counts use different separators or numbering systems from the rest of the dashboard when the browser and WordPress user locales differ.

• Format all seven report-table count fields with the shared formatMetricValue helper.
• Preserve full table precision by explicitly disabling compact K/M multipliers.
• Add regression coverage that prevents these fields from falling back to browser-locale formatting.

Related product discussion/links

• WOOA7S-1748

Does this pull request change what data or activity we track or use?

No.

Testing instructions

• Run pnpm test -- --runInBand routes/reports/count-fields.test.tsx from projects/packages/premium-analytics.
• Confirm the test covers the Posts, Archives, Comment Subscribers, Videos, File downloads, and Clicks report count fields.
• Build Premium Analytics with pnpm run build and confirm the reports route builds successfully.
• Optionally set the WordPress user locale and browser locale to different locales, then confirm report-table counts follow the WordPress locale and retain full values rather than K/M abbreviations.

[jp-launch-control]

Code Coverage Summary

This PR did not change code coverage!

That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷

Full summary · PHP report

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

[layoutd]

✅ LGTM, with a shared field adapter recommended as a follow-up.

This correctly replaces browser-locale formatting with the shared Premium Analytics formatter, so report counts respect the WordPress locale while continuing to use Latin digits. The implementation is appropriately scoped, and the targeted formatter tests pass.

Before, in ar-EG

After

Non-blocking follow-up

Several reports added after this PR branched (Search Terms, Referrers, UTM, Emails, Insights, Comments, and Tags) copied the previous toLocaleString() pattern, so they do not inherit this fix automatically – merge trunk and update them too.

In the long term, maybe we should consider adding a shared semantic report-metric field adapter in widgets-toolkit that preserves raw numeric values for sorting and filtering while using formatMetricValue() for display. It should distinguish counts, averages, percentages, and ungrouped values such as years, with a guardrail preventing direct toLocaleString() usage. Existing reports would require a one-time migration, after which future reports would receive correct formatting by default.