Localize numbers server-side (maintainers' opinion requested)

[yardenshoham]

This one started when I encountered #12637. I wrote RenderNumber in b9319f9 to format the number of commits, then I thought "Why not format all other numbers in a nice way?". So I did it in c929ad2.

While running a search for numbers in templates I encountered JsPrettyNumber and CountFmt. JsPrettyNumber seems to localize the numbers client-side (therefore with a "flash of unstyled content") and CountFmt does it server-side disregarding the user's locale. So this PR can go a few ways:

1. Land RenderNumber + use it in the places of c929ad2 (current PR state)
2. Do 1 + refactor the codebase to use only RenderNumber and drop JsPrettyNumber and CountFmt
3. Drop everything I did and just use JsPrettyNumber for number of commits

What do you prefer?

[delvh]

I don't think we can drop CountFmt as that suffixes with k/ M/ G, and I don't want to have for example 7,654,321B instead of 7.6MB but perfectly localized.
Then, in favor of pure JS side rendering is that it knows best how to format a number for the user.
Against the JS solution speaks especially that it needs JS, and a bit of frontend time, which is especially bad for users with bad hardware or users that disable JS.

Hmm, I don't think that is a strong enough argument not to push the work to the frontend.
So I'm probably in favor of rendering all numbers (where possible) in the frontend.

[yardenshoham]

Thanks @delvh, looks like a vote for option 3

[lunny]

The frontend language should not always follow web browser, it's a default option. And users could set their prefer language which maybe different from web browser. And for a more complicated example, users' prefer location and language should become two options, but I think we currently can hold only one.

[6543]

I think that's a frontend concern and should be in JS code ...

[yardenshoham]

Option 3 decided then, thank you all

[yardenshoham]

Continued in #21786

[6543]

still thanks ❤️