Comment by sjrd

Comment by sjrd 19 hours ago

11 replies

View on Hacker News

I am one of the maintainers is the Scala compiler, and this is one of the things that immediately jump to me when I review code that contains any casing operation. Always explicitly specify the locale. 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.

Also, this is the last remaining major system-dependent default in Java. They made strict floating point the default in 17; UTF-8 the default encoding some versions later (21?); only the locale remains. I hope they make ROOT the default in an upcoming version.

FWIW, in the Scala.js implementation, we've been using UTF-8 and ROOT as the defaults forever.

mormegil 11 hours ago

I agree that Locale.ROOT is the canonical choice. But in this case, Locale.US also makes sense: it isn't some abstract "US is some kind of the global default", it is saying "we know are upcasing an English word".

Reply View 1 reply
  • fukka42 5 hours ago

    Wouldn't the British locale make more sense then?

    Reply View 0 replies
JuniperMesos 17 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.

I have no idea what `Locale.ROOT` refers to, and I'd be worried that it's accidentally the same as the system locale or something, exactly the sort of thing that will unexpectedly change when a Turkish-speaker uses a computer or what have you.

Reply View 8 replies
  • layer8 16 hours ago

    > I'd be worried that it's accidentally the same as the system locale or something

    The API docs clearly specify that Locale.ROOT “is regarded as the base locale of all locales, and is used as the language/country neutral locale for the locale sensitive operations.”

    Reply View 0 replies
  • troad 14 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.

    Reply View 5 replies
    • Symbiote 9 hours ago

      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.
      Reply View 1 reply
      • brainwad 4 hours ago

        That's not the American date format, either - which would be Oct 13 2025.

        Reply View 0 replies
    • outadoc 7 hours ago

      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?

      Reply View 0 replies
    • sjrd 13 hours ago

      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.

      Reply View 1 reply
      • [removed] 10 hours ago
        [deleted]
        Reply View 0 replies
  • kevin_thibedeau 16 hours ago

    It is a programming language agnostic equivalent of POSIX C locale with Unicode enhancement.

    Reply View 0 replies