Bug 711 - Esperanto locale (currently for France)
Summary: Esperanto locale (currently for France)
Alias: None
Product: glibc
Classification: Unclassified
Component: localedata (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Petter Reinholdtsen
Depends on:
Reported: 2005-02-09 21:51 UTC by Jean-Charles Salzeber
Modified: 2005-09-24 19:07 UTC (History)
1 user (show)

See Also:
Last reconfirmed:

Esperanto locale for france (1.68 KB, text/plain)
2005-02-09 21:52 UTC, Jean-Charles Salzeber

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Charles Salzeber 2005-02-09 21:51:04 UTC

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.

Comment 1 Jean-Charles Salzeber 2005-02-09 21:52:22 UTC
Created attachment 401 [details]
Esperanto locale for france
Comment 2 Ulrich Drepper 2005-09-24 19:07:34 UTC
Artificial languages will never be supported.