Hi,

There has been several discussions about this in the past, but it seems that no
one have gotten a clear answer at this time.
 
Actually there is a real need for an esperanto locale in glibc. Debian patch the
libc adding an eo_EO locale, Mandrake add an eo_XX locale, and many users patch
their system themselves. There are several Esperanto Howto with each one a
different esperanto locale. The problem is that unfortunatly (for a locale
developer's point of view), esperanto speakers are widely scattered, so they are
not bounded to one or few countries.

At http://www.student.uit.no/~pere/linux/glibc/howto.html this statement can be
read:« the glibc maintainers seem to refuse "artificial languages" like
Esperanto and Lojban, even if they got a ISO 639 code. »
 
The "seem to refuse" leave me confused. I guess that "artificial languages"
means "artificialy created languages", since Esperanto is not more artificial
than any language, it's spoken by millions (between 2 and 10, depending on the
source) of people, and even on a daily basis. And the "artificialy created"
wouldn't be a better argument to refuse it, since you should then also refuse,
for example, modern hebrew, turkish or in fact any language.

This bugreport is an attempt to get Esperanto included in the glibc to avoid the
actual chaos, or at least have a *clear* answer why would Esperanto be refused.

For an Esperanto locale there're different alternatives:
 - a "generic" (i.e. not bound to any country) locale with the name eo, eo_EO or
eo_XX. I personnaly think that eo_EO is definitively not to be considered.
 - many per-country locales: eo_US, eo_FR, eo_ES, ... (idealy they would share
many data with others locales: en_US, fr_FR, es_ES...)
 - a combination of both a generic and many per-country locales so that each
locale would be very minimal (in fact just LC_IDENTIFICATION and LC_ADDRESS).
The generic one may or may not be allowed, so added in the SUPPORTED file.
 
My personal choice would be the third. A generic locale would obviously miss
many data, since it would simply share LC_NUMERIC, LC_MONETARY, LC_PAPER,
LC_ADDRESS and LC_TELEPHONE with the "i18n" pseudo-locale. Currently, Debian and
Mandrake choosed a worst solution IMO, that is they choose the author's country
as reference, so it doesn't fit well for other users.
If someone fears the maintaining cost of these locales, well, several esperanto
speakers and I would actually do the job so it doesn't seem to be a problem.
 
As a practical example, I join an eo_FR, Esperanto locale for France, which
would be a locale of the second alternative. I will really appreciate answer,
correction or advice, especially if it leads Esperanto locale(s) being accepted
in the GNU libc.

Regards,
JC