As someone who has written scientific software, I have had occasion for needing various number formats based on program semantics, not localization, so +1 for the concept that if a parameter exists, it should be as specific to its task as possible (e.g., NumberFormat). Locale is a kind of service registry for acquiring such instances, and if in the future someone finds it much more convenient to pass Locale and have the NumberFormat extracted from it, he can use an extension method to wrap the specific call (and perhaps if useful enough it could be published in a dependency).
Christopher Smith On Sun, Jul 12, 2026, 00:17 Jochen Theodorou <[email protected]> wrote: > > > On 7/12/26 02:45, Paul King wrote: > > Good point Jochen. I am not sure I understood the full picture of > > where you'd like to head, > > well, I did not want to give a definitive direction. I wanted to start a > discussion that then hopefully will result in an understood decision. I > am aware that what I was talking about is probably a bit opinionated. > > to explain my point of view a bit more. The Laptop I use for development > has LANG currently set to en_US.UTF-8 ( default Locale would be set > accordingly). But frankly the key point for the system here is UTF-8. > Not en_US. And a CI may also have a locale like that. I am using the > en_US locale mostly because I do not want to have for example > "germanization" of menus from my system UI. It is a pain if you have to > search for how to configure something in your window manager for > example. Also the localization under Linux is often incomplete or has > non-idiomatic translations. > > At the same time I develop applications for Swiss and German customers. > They do not want to see a US locale. They want to see dates and numbers > in Swiss or German format, they want to see the user interface (textual > or graphical) using maybe English, maybe Swiss-German, Swiss-Italian, > Swiss-French, or German. I also had once an application that > additionally had to support Spanish. The Spain-Spanish, to be exact. And > if I have to support currencies, they are usually not singular. For > example CHF and EUR at the same time. > > > but I tried to capture in a ticket some of > > what you said folded in with the JDK builtin "Best Practices": > > > > * Use Locale.ROOT for any data that is meant for machines, protocols, > > file formats, network code, or internal database keys. > > * Use Locale.getDefault() exclusively when you are rendering text, > > dates, numbers, or currencies directly onto a user interface for a > > human to read. > > > > But we can debate how we might further tweak those best practices. > > > > Jira ticket is here: > > https://issues.apache.org/jira/browse/GROOVY-12152 > > Locale.ROOT sounds good. But do we really want to add all those Locale > variants to the methods in the first place? Plus, is Locale even the > right contact point? > > then there is the question of "what is machine facing code". If I have > to write timestamped values I usually want to write the time in UTC, > maybe a shortform of it, and the values in non grouping mode. But there > is no Locale for this. > > This is form the javadoc of Locale: > """ > [...] > The Java Platform provides a number of classes that perform > locale-sensitive operations. For example, the NumberFormat class formats > numbers, currency, and percentages in a locale-sensitive manner. Classes > such as NumberFormat have several convenience methods for creating a > default object of that type. For example, the NumberFormat class > provides these three convenience methods for creating a default > NumberFormat object: > > NumberFormat.getInstance() > NumberFormat.getCurrencyInstance() > NumberFormat.getPercentInstance() > > > Each of these methods has two variants; one with an explicit locale and > one without; the latter uses the default FORMAT locale: > > NumberFormat.getInstance(myLocale) > NumberFormat.getCurrencyInstance(myLocale) > NumberFormat.getPercentInstance(myLocale) > > > A Locale is the mechanism for identifying the kind of object > (NumberFormat) that you would like to get. The locale is just a > mechanism for identifying objects, not a container for the objects > themselves. > [...] > """ > > And the last sentence is the key here. Even if I define a custom Locale > for my needs, NumberFormat.getInstance() would not know about it. I am > instead forced to have my own NumberFormat instance, that is configured > to my needs. And that is what then would have to be used for the > formatting of numbers, not the Locale. So maybe those methods should > take NumberFormat instead of Locale? Just putting that out here to > challenge the current implementation idea. > > Just in case someone is interested... The way to make > NumberFormat.getInstance(myLocale) pick up my custom format would be to > write an SPI provider. And there is no programmatic way for this I would > know. > > bye Jochen >
