← Back to context

Comment by troad

18 hours ago

> However, unlike TFA and other comments, I don't suggest `Locale.US`. That's a little too US-centric. The canonical locale is in fact `Locale.ROOT`. Granted, in practice it's equivalent, but I find it a little bit more sensible.

Isn't it kind of strange to say that Locale.US is too US centric, and therefore we'll invent a new, fictitious locale, the contents of which is all the US defaults, but which we'll call "the base locale of all locales"? That somehow seems even more US centric to me than just saying Locale.US.

Setting the locale as Locale.US is at least comprehensible at a glance.

I guess it's one way to look at it. I see it as: I want a reproducible locale, independent of the user's system. If I see US, I'm wondering if it was chosen to be English because the program was written in English. When I localize the program, should I make that locale configurable? ROOT communicates that it must not be configurable, and never dependent on the system.

I am surprised to find Java's Locale.ROOT is not American.

  DateFormat dateFormat = DateFormat.getDateInstance(DateFormat.DEFAULT, Locale.ROOT);
  System.out.println(dateFormat.format(new Date()));

  dateFormat = DateFormat.getTimeInstance(DateFormat.DEFAULT, Locale.ROOT);
   System.out.println(dateFormat.format(new Date()));

  NumberFormat numberFormatter = NumberFormat.getNumberInstance(Locale.ROOT);
  System.out.println(numberFormatter.format(12.34));

  NumberFormat currencyFormatter = NumberFormat.getCurrencyInstance(Locale.ROOT);
  System.out.println(currencyFormatter.format(12.34));

  2025 Oct 13
  10:12:42
  12.34
  ¤ 12.34

Even POSIX C is less American than I expected, with a metric paper size and no currency symbol defined (¤ isn't in ASCII). Only the American date format.

I assume that Locale.ROOT will stay backwards-compatible, whereas theoretically Locale.US could change. What if it changes its currency in the future, for example, or its date format?