An esperanto locale is already included with Debian and Mandrake. According to Ethnologue (www.ethnologue.com) Esperanto has around 2,000,000 second-language speakers in 115 countries. Compare with other minority languages, like basque eu_ES (580.000) or Breton br_FR (500000). I hope the maintainers don't engage in a linguistic discussion about language categories (that does not belong here) and acknowledge the simple fact that lots of their users actually patch the system in order to have this locale and would like to have included. In certain contexts, not having the locale for esperanto means that no localization is possible. Why would you intentionally hinder those projects? That has nothing to do with glibc goals, does it? In case you don't know, the UN system through UNESCO has passed favorable resolutions on Esperanto. UNESCO also has called for language diversity in the Information Society. I find it hard to believe that you can simply reject the requests to add the locale. [1] http://unesdoc.unesco.org/ulis/dec_res.html (look for esperanto)
Created attachment 823 [details] Esperanto (Uruguay) locale
Created attachment 874 [details] Esperanto (Uruguay) locale revised Added missing bits for Uruguay
No locales for artificial languages will ever be added.
There are several considerations here. If there are ISO standard language codes and user communities who maintain the translations, then there is no reason not to take a language no matter how few people really use it. For locales, if there is an ISO code and a recognized standard specifying the details, there is no reason not to take them. There is already a backlog of locales for languages spoken by children that warrant examination, at a higher priority than locales for languages spoken only by adults. We should get a regularized and streamlined procedure for dealing with locale stuff. We plan to judge requests for new locales like any other features that users ask for: by how many users would like them and how pressing their needs are, by who offers to do the work, and by the practical problems of having the GNU C library support the features. For now, it seems to be a good idea to let Debian and Mandrake's glibc ports experiment with this particular request and see how well it works in practice. We can revisit the suggestion later for glibc itself.
Mandrake has had an esperanto locale (eo_XX) for at least six years and Debian (eo_EO) for seven years. Do you really think that there is a need for further experimentation? On the other hand we've been trying to add the locale to glibc since 2001 if I remember correctly. While I'm glad to hear that the request for an esperanto locale will be judged like the requests for any other locale, I think the glibc team has by now enough information and external testing. If that's not the case, please don't hesitate to ask.
Subject: Re: Please add esperanto locale (eo_UY) While I understand your comments[1], I think that it's not appropiate to leave the bug closed as WONTFIX stating that sometime in the future you will take care of it. Debian has had an esperanto locale (eo_EO) for at least seven years and it simply works (for example, the Debian webpages are built using it). There is nothing technically weird about this locale. Do you feel there is a need for further experience? We've been asking for many years (from 2001 at least) to add an esperanto locale to glibc. We've tried everything, from simple "eo" to "eo_XX" and now "eo_country code". What do you suggest we have to do to have glibc accept an esperanto locale in one of the proposed forms? (eo_XX, eo_FR, eo_UY). We understand that eo_EO is wrong and that eo_XX might be not acceptable to you because XX is private, although it is the preferred form. But what about eo_UY? Thanks, Eduardo. PD: Since you brought it up I have to add that there are native speakers, so the language is spoken by adults and children. [1] http://sourceware.org/bugzilla/show_bug.cgi?id=2135#c4
I stand corrected; there are a very few native speakers of Esperanto. But this doesn't affect the main point, which is that the most important problem here is coming up with a streamlined and regularized procedure for working through the locale backlog for glibc. We'd like to get this working so that we can handle requests like this better in the future. It would be an inefficient use of our limited resources to review requests for eo_UY, eo_US, eo_GG, eo_XX, etc., without having a reasonable procedure in place.
Subject: Re: Please add esperanto locale (eo_UY) Hello, I've just seen the new Kashubian locale for Poland added without any hassle whatsoever, even with help from the people who do the checkins, in little more than a week[1]. Am I to assume you finally found a way to streamline the addition of new locales? Friendly, Eduardo. PS: I have nothing against the insertion of Kasubian, but check some facts[2], I really don't understand your policy, unless it's changed for the good and we are next ... Population 3,000 in Poland. Language use The Slovincian dialect is extinct. Few children speakers of Kashubian Proper. [1] http://sourceware.org/bugzilla/show_bug.cgi?id=2961 [2] http://www.ethnologue.com/show_language.asp?code=csb > ------- Additional Comments From eggert at gnu dot org 2006-05-25 07:13 ------- > I stand corrected; there are a very few native speakers of Esperanto. But this > doesn't affect the main point, which is that the most important problem here is > coming up with a streamlined and regularized procedure for working through the > locale backlog for glibc. We'd like to get this working so that we can handle > requests like this better in the future. It would be an inefficient use of our > limited resources to review requests for eo_UY, eo_US, eo_GG, eo_XX, etc., > without having a reasonable procedure in place. >
There will not be any support for any artificial language. Period.
Subject: Re: Please add esperanto locale (eo_UY) > There will not be any support for any artificial language. Period. Read comment #4 and #5. You are saying that what Paul Eggert said should not be taken into account in any way?
(In reply to comment #8) > Subject: Re: Please add esperanto locale (eo_UY) I think this data: > Population 3,000 in Poland. is obsolete. Census from 2002 in Poland shows that more than 50,000 people use Kashubian as a first (native) language at home, so there are more than 3,000 people in Poland who make the Kashubian population. On that Ethnologue page there is also other information, which you forgot to paste: Ethnic population: 100,000 or more. Well, this discussion is not about Kashubian language, I just wanted to correct this information which Eduardo wrote. Cheers, Michal
Subject: Re: Please add esperanto locale (eo_UY) Thanks for the correction. My comment wasn't aimed at the Kashubian language, as you well noted, but at the (lack of public and official) policies to add new locales.
It seems to me that while LANG and LC_* may only contain valid locale names (since these variables are involved in the setlocale() call that handles structures representing existing locales), the variable LANGUAGE which I guess is only involved in gettext may take arbitrary value. So for example even if there's no esperanto locale on your system, this setup seems to be perfectly valid and working for me: LANG=en_US.UTF-8 LANGUAGE=eo and then translations are primary taken from the "<localedir>/eo" directory. LANGUAGE can even take more language codes separated by ':', e.g. LANGUAGE=eo:de to fall back to German for each string where esperanto translation is not available. This means that you can translate your application to Esperanto even if there's no such locale. What is still missing is the stuff coming from the locale database: month and weekday names, first day of week in calendar, localized date format, decimal separator and grouping character, yes/no regexp, collation etc...
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.
. *** This bug has been marked as a duplicate of bug 16190 ***