Hi,
On Thu, Dec 16, 1999 at 11:17:46AM +0100, Jochen Hoenicke wrote:
> On Dec 15, Mark Wielaard wrote:
> > The java.lang.String methods toLowerCase() and toUpperCase() can take a
> > Locale. But they currently don't use it (but use the methods in Character
> > which don't take a Locale).
>
> AFAIK the only locale specific thing is that for turkish local, which
> has two different i's one with dot, and one without. For most locales
> the unicode uppercase or lowercase is sufficient.
That is the example that the Sun Javadoc gives, but are you sure that is the
only language that has such rules? Note that I don't know that much about
other languages/scripts. And I guess it is not a very high priority if the
only locales Classpath currently supports are English, German and Dutch :)
> > For the other classes that implement getAvailableLocales() (or actually
> > don't implement it) wouldn't it be possible to package the locales in a
> > separate jar file and then always load the ResourceBundles through a
> > URLClassLoader (which we should then first implement :) using that jar so
> > we can also search which classes are available in the jar file?
>
> You are right, we should only return locales for which we have a
> localization. But I think we can't use the implementation you
> suggest.
You are right. I actually started on implementing URLClassLoader (and will
send it to you when I finish it and the documentation) but it extends from
SecureClassLoader which is a 1.2 Class that depends on some 1.2 features
of ClassLoader that are not yet implemented (so I guess that is not the way
to go :)
> We must call the getResource on the class loader that loaded
> the class, like ResourceBundle does, to support virtual machines that
> have their own special class loading mechanism. This means we can't
> get a list of resource bundles easily.
>
> I suggest adding an entry to the root resource bundle, listing the
> available locales.
Would it be an idea to supply a simple properties file (say gnu.locales)
with that information? That would make it simpler for people that want to add
their own Locales. By providing an extra properties file (with the same name)
and their LocaleInformation classes in a directory/zip/jar which people can
just add to their classpath (you can then merge those property files by
doing a ClassLoader.getResources("gnu.locales")).
To bad that the Locales are so underspecified. It could have been such a
nice simple idea.
Bye,
Mark
