From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113849 invoked by alias); 20 Nov 2018 12:02:54 -0000 Mailing-List: contact libc-locales-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-locales-owner@sourceware.org Received: (qmail 113479 invoked by uid 48); 20 Nov 2018 12:02:47 -0000 From: "carmenbianca at fedoraproject dot org" To: libc-locales@sourceware.org Subject: [Bug localedata/23857] Esperanto has no country Date: Tue, 20 Nov 2018 12:02:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: localedata X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carmenbianca at fedoraproject dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2018-q4/txt/msg00117.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23857 --- Comment #8 from Carmen Bianca Bakker --- (In reply to Rafal Luzynski from comment #7) > Thank you. I have not looked at the source code yet but my guess is that > the list of territories comes from the list of locales with language part > stripped. This makes some sense to me: formats, units, etc. depend on the > territory rather than language. For example, English locale may have > different units, currency, country name etc. for USA, UK, Australia, Indi= a, > Ireland, and so on. On the other hand, people living in one country > probably use the same formats, units, and currency even if they speak > different languages. Therefore, if you want to select "Esperanto" as the > locale for formats then... actually what would you expect? Currency, > country name, address format, car plate - "as used in (where?)" Why > "Netherlands" would not work better for you, for example? The chief problem in selecting "Netherlands" is that LC_DATE won't have the correct language. I would much rather individually select each LC_* option, but GNOME does not support that in its graphical interface. > > https://bugs.python.org/issue35163 - Some weird obsolete configuration. >=20 > My first suggestion is that Python should not map ambiguous locales into > detailed ones but not supported by the current operating system. >=20 > Would adding "eo.ISO8859-3" help to fix this issue? I think the reason is > that historically the locales without the encoding specified used 8-bit > encoding like ISO 8859-1 or ISO 8859-3. Therefore often the locales map = to > 8-bit encodings unless you specify "utf8" explicitly. Later when Unicode > became popular and widely used, newly added locales in glibc used UTF-8 as > their only encoding. This is the case of Esperanto: "eo" is an alias of > "eo.UTF-8". Somehow Python treats it as an alias of "eo_XX.ISO8859-3". >=20 > On the other hand I am not sure if adding the old encodings makes sense > nowadays. Old encodings are preserved only in order not to break existing > systems. Does any existing Linux system use "eo.ISO8859-3" and rely on i= t?=20 > Is it likely to be true if this locale has never existed? I don't think anything needs to be changed from glibc's end for this bug. = This appears to be a Python-only oddity---I have never encountered eo.ISO8859-3 anywhere else. > It is possible as a workaround but I still believe we are able to handle > "eo" without a country name. Even more: we (the glibc project) are able = to > handle it and as there are projects which do not (yet) handle it correctl= y I > think we should rather approach them and tell them how to fix it. So far= I > don't think we have found any project where the issue exists and cannot be > fixed. I don't disagree, but wouldn't changing this in glibc be a much easier solu= tion compared to the laborious process of opening bug reports everywhere to hand= le a special case? For instance, if we assume for a moment that "ia_FR" will become "ia", then= a lot of packages in a lot of distributions will need to change their for-loo= ps to `for eo ia *_*`. This is cumulatively a lot of work for minority langua= ges. A simple "ia_ZZ/eo_ZZ" would remove the special case and save a lot of wor= k. > Definitely no, Yiddish is not an artificial language and definitely is > related with some territories where it is actually spoken. It seems to me > that Israel could make sense and I don't mind adding it if needed, probab= ly > also USA makes sense. I don't think that calling Yiddish "worldwide" or > "non-US" or "unknown" (in terms of territory) makes sense because we can > tell the same about any random language. I didn't imply that Yiddish is an artificial language. I implied that havi= ng a catch-all "yi_ZZ" would save a lot of work over creating individual locales= for all the countries in the world where Yiddish is spoken in some capacity, wh= ich is a lot of countries. In that capacity, Yiddish is an excellent compariso= n to Esperanto, because both languages have a diaspora across the globe rather t= han a defined nation state. --=20 You are receiving this mail because: You are on the CC list for the bug.