This is broken. BTC has always intentionally used locale-independent formatting so it is written the same way internationally.

It should always render as: 123,456.78 μBTC

Meh. Many people do like it with local formatting. Maybe make the number
locale configurable separately from the language and default to US.

Todo: make sure that this doesn't affect URI amount parsing.

@luke-jr It doesn't always render as 123,456.78 μBTC though. The issue that I recently filed, #3887, came about because the balance currently renders as 123456789.00 μBTC, which is not very decipherable (it needs some kind of places delimiter).

@laanwj Doesn't mean we should accomidate it... Bitcoin should be internationally recognisable. If we do accomidate localised-BTC, by the same logic we should merge TBC support also.

@CydeWeys I agree the commas should be added.

@Drak Can you help testing this in whatever locale you're in?

@Drak Thanks for testing so quickly!

@BitcoinPullTester there appears to be an issue with Bitcoin URIs. I thought I handled this by always parsing the amounts in the C locale ( https://github.com/bitcoin/bitcoin/pull/3893/files#diff-a459a939be4fe065dd5f64ab60bb30d0R136 ), but something is going wrong. Need to fix this before this can be merged.

Ok, Bitcoin URIs work again as they're supposed to. This was sneaky, in Qt <5.0 to the QLocale.toLongLong has a 'base' argument that [in the 'c' locale] defaults to 0 which amounts to 'auto detect base'. '0100000' was interpreted as octal! In Qt>=5.0 the base is always 10.

TODO:

• add some unit tests for various locale
• add a GUI option to set the bitcoin amounts locale separately from the default/system locale.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/a8c9ed2ecf40386de5bc93e4796948714e6f2e93 for binaries and test log.
This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/
Contact BlueMatt on freenode if something looks broken.

TODO:

• check fa_IR locale and other locales with non-latin numerals, if I can make no sense of them, exclude them for now

@laanwj Thanks for all of your hard work. This is going to be an awesome new feature.

I agree with @luke-jr on this one. If we want more readable large numbers, using thin spaces as a thousand seperator is a better option imho since it's unambigious between all locales.

Also, how does locale-aware parsing affect me if I use the old format? Say I am a Dutch. So far, entering 1.234 Bitcoins when sending Bitcoins always sent just over one Bitcoin. Would this suddenly send over 1000 Bitcoins with this change?

@leofidus No, it will still default to US. However people who want number formatting/parsing in their own locale can do so. Please read my actual posts instead of spreading FUD.

@laanwj I am referring to after I changed the setting, but while I am still in the habit of using the old way. I admit that I did not express that clearly.

@leofidus Sure, if you set the setting to your locale and keep using the US decimal seperator it's possible to mess numbers up.

The confirmation dialog in 0.9 shows you the total amount formatted in all units (w/ at least two decimals), so 1.234,00 BTC, 1.234.000,00 mBTC and 1.234.000.000,00 uBTC. The extra set of decimals would be a hint...

Also: arguably a new user from the Netherlands will expect Dutch decimal/group seperators and already mess things up, as that has been our 'old way' for hundreds of years. There was already this risk...

Reluctantly closing this in favour of #4167.