This is the mail archive of the
libc-locales@sourceware.org
mailing list for the GNU libc locales project.
[Bug localedata/10580] New file for hr_HR localedata
- From: "pasky at ucw dot cz" <sourceware-bugzilla at sourceware dot org>
- To: libc-locales at sourceware dot org
- Date: Sat, 16 Feb 2013 00:39:45 +0000
- Subject: [Bug localedata/10580] New file for hr_HR localedata
- Auto-submitted: auto-generated
- References: <bug-10580-716@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=10580
Petr Baudis <pasky at ucw dot cz> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
CC| |pasky at ucw dot cz
--- Comment #10 from Petr Baudis <pasky at ucw dot cz> 2013-02-16 00:39:45 UTC ---
Dragan, thank you for your work.
It is true that the locales in glibc are not fully ISO/IEC 14652 compliant, in
particular some fields that should be used in fact are not. I'm not personally
sure why this is the case, probably it's for purely historical reasons.
However, I believe the greatest value lies in consistency, and if no current
locales use %n in postal_fmt and %e and %t in tel_*_fmt, neither should hr_HR
as the programs using these locales probably do not expect to find these field
descriptors there.
So let's not conflate the issue of unsupported field descriptors with the new
hr_HR locale; could you please submit an hr_HR locale version that does not use
these field descriptors? Since you got a buy-in from other Croatians active in
this area, I think we can commit the new locale speedily afterwards.
(Regarding the issue of unsupported field descriptors, if you are interested in
pursuing that further. A simple technical fix is to simply patch
locale/programs/ld-{telephone,address}.c to allow these. However, we should do
this with consideration to locale consistency and current usage of these
categories in programs. This needs to be researched and I think the next
reasonable step is to document the currently supported field descriptors in
"glibc style locales". We can then think of how to proceed further while our
users will already have a valuable reference. This process can be done
gradually, category by category. Does that sound sensible?)
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.