Thanks, looks like different organisations handle this differently. And Unicode known to be very language- and locale-aware could pay closer attention to some element's i18n while in other cases (TemporalUnit is said to be fuelled by exactly the same CLDR and it has no getDisplayName() while Chrono or Timezone do in 310
) it is left to users and apps themselves.
ISO however, does maintain just a single, non-localized name of a currency, see the Swiss(!) local branch of it and a recent change; Oh and last but not least, ISO itself also maintains an English currency name.
Here is its complete set of currencies in Excel or XML form
While Entity is a pointer to either Locale or Region, the following attributes match those in CurrencyUnit, except the missing name:
Minor unit is the equivalent of defaultFractionDigits, the other 2 are *Code() methods.
To honor those sources maybe we should also keep a "name" or "description" field, otherwise it leads to fragmentation among implementations.
Whether or not CurrencyUnit should follow the pattern of TemporalUnit and simply store the ISO or other data source's (usually English) descriptive name and call it getName() or similar, or go along the lines of JSR 310 Chrono/Timezone with a getDisplayName() method, remains to be seen, but for backward compatibility with java.util.Currency if the getDisplayName() version was preferred, I'd also keep the no-op getDisplayName() eventually leaving it to an implementation, if it uses the name as provided by the source/stream or according to Locale.getDefault().