Name: dbT83986			Date: 08/15/99


The locale classes needs support for setting and getting various
variables.
Third party packages only use Locale as input to determine how
different stuff is going to be renedered. Example is KL Group's
JCField. Since the locale info is stored in static classes 
(Resources) it is not possible to change desired properties.
For instance I am right now working on a bank application. 
Displaying most stuff in localized ways are ok but the amounts
should look  the same all over the world. This is easily understandable
since the traders work with many different applications and those
use the same way of displaying the amount. Then it is not good
if one application all of a sudden starts showing stuff in a
completely new format. Such a behaviour would force us to hard
code the locale to US and then the whole idea about localization
is lost.
We need more freedom if we are ever going to be able to use
localization.

========================================
REVIEW NOTE 8/22/99 - User responded with additional information

My thought is something like that I want to for instance use the German
locale but specify that it in this application it should format the dates
according
to the ISO standard.
The code would be something like:

Locale germanLocale = Locale.GERMAN;
Locale isoLocale = Locale.ISO;
germanLocale .setDateFormat(isoLocale.getDateFormat());

This way I don't have to think about which locale to use
for which field, I simply use my customized all the way.

A good thing would be to provide a locale containg the ISO standards
(as you can see above).

Another thing I would like to see is a way to easily extract locale data.
Example code:

Locale locale = Locale.getDefault();
String decimalSign = locale.getDecimalSign();

It is quite common that you as a programmer has to mainpulate
the strings and if it is localized then some characters are going to
differ so you need to be able to extract those characters.

The examples are (I think) possible to handle in the current situation,
they are just provided to give a rough idea about what I'm thinking.
The exapmle versions is at least a lot easier to use than the current
implementation.
Hopefully I've managed to convince you to include this in the future:-)
(Review ID: 93599) 
======================================================================