[i18n] Format numbers according to locale

[benknight]

Very large numbers are left unformatted in TablePagination, for example:

<TablePagination
  rowsPerPageOptions={[25, 50, 100]}
  component="div"
  count={103177}
  rowsPerPage={25}
  page={0}
/>

Probably it should get formatted via Number.prototype.toLocaleString()

Benchmarks

• https://react-spectrum.adobe.com/react-aria/useNumberFormatter.html

[oliviertassinari]

@benknight Thanks for opening this issue. You can find the same issue in Ant Design under ant-design/ant-design#19337. So far, we offer the same solution, meaning developers can customize the labelDisplayedRows prop to format the number based on their locale. It's the current workaround. It's not ideal, I have tried to work on it in the past under #20656 but it didn't fly.

---

In the data grid, we have partially solved the problem with the solution you are proposing:

  valueFormatter: ({ value }) => (value && isNumber(value) && value.toLocaleString()) || value,

the source of the data grid

However, this solution is not compatible with server-side rendering nor used everywhere:

• The server local might not be the same one as the one you are using. So far, the data grid isn't rendering number server-side, but once we solve [DataGrid] Remove headerHeight prop mui-x#602, it will happen, cc @dtassone. We can further improve SSR with [data grid] Initial SSR render support mui-x#7599.
• We can reproduce the same bug in the DataGrid [data grid] Format row count numbers in pagination mui-x#13222:

https://mui.com/x/react-data-grid/pagination/

---

At this point, I think that we could explore these solutions:

1. Ignore the SSR mismatch that can come from Intl.NumberFormatter/.toLocalString(locale), with the use of the suppressHydrationWarning prop https://react.dev/reference/react-dom/components/common#common-props.
2. Move the LocalizationProvider from the pickers to Base UI
3. Create a useLocalization() internal hook to use it in the components
4. Have this hook expose a formatNumber() helper.
5. Have formatNumber() be an abstraction on top of Intl.NumberFormatter API. Similar API to toLocaleString.
6. Encourage https://formatjs.io/docs/polyfills for developers that need SSR with a different locale than the default one (en-US). The data set used by the browser and server for Intl.NumberFormatter might not be exactly the same, leading to hydration mismatch.
7. Cache the different instances of Intl.NumberFormatter as it's slow to initiate, probably reading in the fs to load the right data in RAM. It would be a performance killer for rendering 100 numbers in data table cells.
8. Have useLocalization().formatNumber has a default implementation, no making LocalizationProvider required as we do when it needs date-fns or moment installed.

[benknight]

Of course, I neglected to consider that localization is a much larger, nuanced issue when considering SSR. Thanks for enlightening me towards the complexities involved.