A lot of these seem to be the "not America" test.
We’ve spent easily several months of engineering time “fixing” apps that kept picking up these defaults directly or indirectly. E.g.: What regional options does Azure Data Factory use for parsing CSV by default for batch jobs if you deploy an instance in Australia East? Your guess is as good as mine!
It’s especially hilarious considering that all three major operating systems ask these questions up front, just as they as for a password instead of providing a result. Vendors have had to learn the hard way that defaults for some settings are nonsense for 96% of the planet, and now the same companies have forgotten this lesson and will have to learn it all over again.
Sometimes (but not always), it helps to change the locale to en_UK. But then spellcheck becomes confusing...
UK? So far so good: Maybe those time parsing routines will need some brushing up for the 24 hour based clock, and day and month are swapped, but at least the decimal separator is the same. And it's almost the same language, and definitely the same alphabet.
France? Now you're adding accents to the mix, although in a pinch you can just drop them. (Not that it's a good idea, but there's no better solution.) But watch out: Different decimal separator!
Germany? Better rethink that "just drop the accents" solution; it changes the meaning of words, sometimes drastically/embarrassingly so. However, there is a canonical way of transliterating äöü!
Chinese: Obviously, abandon all hopes of using Latin-1. But at least you can use the US decimal separator again :)
As an American, it's really eye-opening to learn other languages and cultures and apply that context to your work in software.
21 -> "eenentwintig" -> "one and twenty"
French gets especially zany:
80 -> "quatre-vingts" -> "four twenties"
I'm sure there's about a million more ways languages have wildly differing concepts of numbers from what you expect. Now repeat the above exercise for numbers, dates, money, names, just about everything.