Bug 14943 - Artificial languages
Summary: Artificial languages
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: localedata (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks: 16190
  Show dependency treegraph
 
Reported: 2012-12-11 12:37 UTC by Michael Moroni
Modified: 2017-03-15 17:33 UTC (History)
10 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
Patch to add eo_FR (2.44 KB, patch)
2013-03-03 17:50 UTC, Neil Roberts
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Moroni 2012-12-11 12:37:16 UTC
Dear Ulrich Dreeper,
Dearest developers,
The time has come to start discussing seriously about supporting artificial languages, such as Esperanto.
Dreeper, during the last years, closed some related bugs as WONTFIX not only without giving any reason[1][2][3][4] but also *insulting* people speaking artificial languages[5].
I'm telling you to seriously discuss about it without creating any walls.
I hope that you reconsider the fact that artificial languages do exist and they are not useless (see Wikipedia page for Esperanto[6]).
I think that it is too silly not to add support for such languages because they are used actively and they are not simply "forks" of other languages
Debian[7] and Mandrake (Mandriva)[8] support eo_EO locale by default, Arch Linux does support eo locale through AUR[9] and I don't know about Ubuntu.
What about fixing this problem by default inserting a patch upstream? In my opinion it should be the most reasonable option to choice.
I hope you read this bug report and make the most intelligent choice.
I'm looking forward to receiving your answer,
- MM

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=2135#c3
[2] http://sourceware.org/bugzilla/show_bug.cgi?id=2135#c9
[3] http://sourceware.org/bugzilla/show_bug.cgi?id=711#c2
[4] http://sourceware.org/bugzilla/show_bug.cgi?id=13190#c2
[5] http://sourceware.org/bugzilla/show_bug.cgi?id=112#c8
[6] https://en.wikipedia.org/wiki/Esperanto_language
[7] http://filewatcher.com/p/libc6-dev_2.2.5-11.8_mips.deb.3020726/usr/share/doc/libc6-dev/changelog.Debian.gz.html glibc (2.1.1-2)
[8] http://ftp.math.utah.edu/pub//Linux/distributions/Mandrake/2005/x86_64/media/media_info/compss
[9] https://aur.archlinux.org/packages/esperanto-locale/
Comment 1 Andreas Jaeger 2012-12-11 21:26:02 UTC
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
Comment 2 Rich Felker 2012-12-11 23:18:35 UTC
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.
Comment 3 Andreas Jaeger 2012-12-12 08:06:57 UTC
(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.
Comment 4 Andreas Schwab 2012-12-12 08:43:35 UTC
If you want to switch only the language set the LANGUAGE variable, see the gettext manual.  Locales are always country specific.
Comment 5 Florian Weimer 2012-12-12 09:13:29 UTC
(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).
Comment 6 Roumen Petrov 2012-12-12 21:31:50 UTC
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.
Comment 7 Rich Felker 2012-12-13 01:28:18 UTC
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.
Comment 8 Andreas Jaeger 2012-12-13 06:52:42 UTC
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.
Comment 9 hpa@zytor.com 2013-01-09 06:05:05 UTC
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.
Comment 10 Neil Roberts 2013-03-03 17:50:32 UTC
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.
Comment 11 Rich Felker 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 "."
Comment 12 keld@keldix.com 2013-03-04 05:43:09 UTC
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
Comment 13 Neil Roberts 2013-03-08 12:24:19 UTC
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.
Comment 14 Carlos O'Donell 2013-03-11 22:19:05 UTC
(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.
Comment 15 Chris Leonard 2013-11-23 16:59:51 UTC
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?
Comment 16 Carlos O'Donell 2013-11-25 14:55:35 UTC
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
Comment 17 ariasuni 2014-08-28 17:21:44 UTC
Any news on this?
Comment 18 Carlos O'Donell 2015-10-16 14:53:44 UTC
Consensus is "eo" should be used without a region. Please submit patches to libc-alpha for inclusion.
Comment 19 Florian Weimer 2017-03-15 17:33:36 UTC
We now have an eo locale, so there is no principled objection to artificial languages anymore.