Bug 14943

Michael, we reworked our position already and recently added Interlingua. I think an Esperanto locale if properly introduced would be welcome. For details see the libc-alpha archives.

A big question for me is what kind of country code to use for it - as well what kind of formats to use for date and time formats.

Could you send a patch to libc-alpha@sourceware.org with a new Esperanto locale and a rationale for the decisions made, please?

Let's discuss on that list what's the best choice is.

Btw. glibc 2.17 has an initial translation to Esperanto just no locale yet.

thanks,
Andreas

Is there a reason locales HAVE TO have a country code? I think, for languages that are not connected to a country, or where for political reasons the language's country is not recognized internationally, it would be very helpful to have traditional locale names of the format "ll" or "lll" instead of requiring the "ll_CC" form. The country-specific parts of the locale like currency, which would not make sense in such a context, could simply be aligned with the C locale.

If said languages are also heavily used in one or more particular country contexts, it would be nice to also add "ll_CC" format locales for them with the appropriate country-specific parts. But I think it's really annoying to force users who want to use the language to choose from a limited set of countries that do not correspond to the country they're in.

(In reply to comment #2)
> Is there a reason locales HAVE TO have a country code?

So far each one has one - and it might be that some of the infrastructure for installing it, requires it. This is something to discuss on the mailing list IMO.

If you want to switch only the language set the LANGUAGE variable, see the gettext manual.  Locales are always country specific.

(In reply to comment #1)
> A big question for me is what kind of country code to use for it - as well what
> kind of formats to use for date and time formats.

Unicode uses ZZ: <http://www.unicode.org/reports/tr35/>

We could follow this example or pick something else from the private use range (say, XN).

I cannot understand why optional territory (an ISO 3166 country code) was read as required in GNU lib C. 
It seems to me we read different manuals or one and the same but interpretation is different.

I share Roumen Petrov's sentiment completely. There is no justification for this arbitrary policy position, which is unwelcoming not only to users of languages that aren't associated with a specific country, but hostile to users' whose countries are not recognized internationally.

Hi, you read far more into my comment regarding countries than intented to say.

I'm not *requiring* a country, I require that the choice of country is well explained and depending on what is done, it is tested that the tools and infrastructure handle it properly.

We have a meta discussion here. If somebody is interested in Esperanto, test the locale, send it to libc-alpha and explain the choices made and let's discuss this.

Since we already have Interlingua as locale and Esperanto as language I suggest to close this bug report as FIXED. The issue has been revisited, now somebody needs to look at specific examples.

Btw. completely artificial toy languages will not get added.

For a root locale "eo" or "eo_ZZ" seems reasonable, but in practice I suspect that Esperanto locales will need to have localizations, i.e. eo_US which uses the U.S. conventions for currency and so on.  Unfortunately "locale" combines a number of partly orthogonal concepts -- some of which may even be user or application specific and need to be overridden.  An example of the latter was a previous employer of mine which had to distribute an "en_US@Transmeta" locale to all systems to support a single application, so that %' could be used to print numbers with underscore thousands separators.

Created attachment 6914 [details]
Patch to add eo_FR

Here's a patch to add an eo_FR locale for using Esperanto in France. I think the French monetary and numeric systems are close enough to what people would expect for an international system so it's also a good general purpose Esperanto locale. It is based the original international locale created by Edmund Grimley Evans but with some changes to localise it to France. These changes are described in the commit message.

> Here's a patch to add an eo_FR locale for using Esperanto in France. I think
> the French monetary and numeric systems are close enough to what people would
> expect for an international system so it's also a good general purpose
> Esperanto locale.

The radix point is a comma. This is pretty much a show-stopper. In the international language of mathematics, radix point is "."

On Mon, Mar 04, 2013 at 12:17:02AM +0000, bugdal at aerifal dot cx wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=14943
> 
> --- Comment #11 from Rich Felker <bugdal at aerifal dot cx> 2013-03-04 00:17:02 UTC ---
> > Here's a patch to add an eo_FR locale for using Esperanto in France. I think
> > the French monetary and numeric systems are close enough to what people would
> > expect for an international system so it's also a good general purpose
> > Esperanto locale.
> 
> The radix point is a comma. This is pretty much a show-stopper. In the
> international language of mathematics, radix point is "."

The ISO radix point is comma, in mathemaitcs too. It is only USA and Canada
and some other English-speaking countries that use the period.

We are talking France, and they are using comma. I don't see this as a show-stopper,
but only natural.

Best regards
keld

So what's the next steps to get this patch landed? Does someone specific need to review it?

I think the comments by Keld cover the concerns with the radix point. There are also some clarification in a widely respected book about Esperanto grammar here:

http://bertilow.com/pmeg/gramatiko/nombroj/matematiko.html

Roughly translated, it says “Don't use a period instead of a comma for decimals. The period is used as a decimal sign only in a few countries. Esperanto, like most countries and languages, uses a decimal comma”. It also shows some examples of using the comma in mathematical writing.

(In reply to comment #13)
> So what's the next steps to get this patch landed? Does someone specific need
> to review it?
> 
> I think the comments by Keld cover the concerns with the radix point. There are
> also some clarification in a widely respected book about Esperanto grammar
> here:
> 
> http://bertilow.com/pmeg/gramatiko/nombroj/matematiko.html
> 
> Roughly translated, it says “Don't use a period instead of a comma for
> decimals. The period is used as a decimal sign only in a few countries.
> Esperanto, like most countries and languages, uses a decimal comma”. It also
> shows some examples of using the comma in mathematical writing.

The next step is to post a final patch to libc-alpha@sourceware.org, CC the people who made comments here, and ask for final review. The post description of the problem should address the concerns raised in v1 of the patch and if any changes were made it should list them under a v2 entry.

Make sure to follow:
http://sourceware.org/glibc/wiki/Contribution%20checklist

One you have consensus then a developer with commit permission can check the patch into master.

I have a suggestion.

Esperanto is currently the language of instruction of the International Academy of Sciences in San Marino

http://en.wikipedia.org/wiki/Akademio_Internacia_de_la_Sciencoj_San_Marino

I propose submitting a locale for eo_SM in recognition of this fact.  It is no more-or-less sound than the logic that lead to for for Interlingua.  Comments?

I've emailed libc-alpha/libc-locles to get consensus on using locales without country codes.

https://sourceware.org/ml/libc-locales/2013-q4/msg00137.html

Any news on this?

Consensus is "eo" should be used without a region. Please submit patches to libc-alpha for inclusion.

We now have an eo locale, so there is no principled objection to artificial languages anymore.