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
