Change 357000 had a related patch set uploaded (by Santhosh; owner: Santhosh):
[mediawiki/core@master] [WIP] Correct the commafy implementation as Unicode TR35 specification

https://gerrit.wikimedia.org/r/357000

Change 384006 had a related patch set uploaded (by Santhosh; owner: Santhosh):
[mediawiki/core@master] Update formatNum implmentation to match tr35 and latest CLDR

https://gerrit.wikimedia.org/r/384006

Change 357000 abandoned by Santhosh:
[WIP] Correct the commafy implementation as Unicode TR35 specification

Reason:
Abandoning in favor of https://gerrit.wikimedia.org/r/#/c/384006

https://gerrit.wikimedia.org/r/357000

One thing to consider is to have consistent formatting both in PHP and JavaScript. For this we actually need generic formatters in both languages, for which we can pass the actual format string (defined in CLDR or specified locally in MediaWiki).

See also T71836: mediawiki.language.numbers.js truncates numbers instead of rounding

See also T237467: Invariant failed: Bad UTF-8 (full string verification) which was tracked down to a bug in the current commafy implementation that produced corrupt UTF-8 sequences.

In T167088#4896103, @Nikerabbit wrote:

One thing to consider is to have consistent formatting both in PHP and JavaScript. For this we actually need generic formatters in both languages, for which we can pass the actual format string (defined in CLDR or specified locally in MediaWiki).

Possibly we could just create a very thin action API to do the formatting in any 'unusual' cases, which would avoid having duplicate code and potential drift between them. If structured correctly, the AJAX query/responses should be very cache-able.

Interesting issues discovered during T237467 is that commafy/formatNum have been used to apply to arbitrary strings, not just numeric strings, and there's a decent amount of sloppiness wrt whether the string it applies to is in latin digits or native digits/separators. This is a side-effect of there being no difference between them in us/euro wikis, presumably, so most people "don't worry" about whether they are using formatNum correctly. Anyway, the cleanups to formatNum/commafy for T237467 are tightening the interfaces which will hopefully make this task easier as well.

Change 384006 merged by jenkins-bot:
[mediawiki/core@master] Update formatNum implementation to match tr35 and latest CLDR

https://gerrit.wikimedia.org/r/384006

Using NumberFormatter seems to cause a loss of precision in numbers that MediaWiki could previously format accurately:

> echo $wgLang->formatNum( '9999999999999999999' ) . PHP_EOL;
9,999,999,999,999,999,999 # 1.35
10,000,000,000,000,000,000 # master
> echo $wgLang->formatNum( '3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938' ) . PHP_EOL;
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938 # 1.35
3.1415926535897930000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 # master

This seems to be the cause of T268456: Value stored and value displayed are different for large numbers.