This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Use Unicode code points for country_isbn
- From: Keld Simonsen <keld at keldix dot com>
- To: Marko Myllynen <myllynen at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Ond??ej Bílka <neleai at seznam dot cz>, GNU C Library <libc-alpha at sourceware dot org>, libc-locales at sourceware dot org
- Date: Mon, 10 Aug 2015 13:05:56 +0200
- Subject: Re: [PATCH] Use Unicode code points for country_isbn
- Authentication-results: sourceware.org; auth=none
- References: <5571B8C2 dot 8000108 at redhat dot com> <20150609071130 dot GA26925 at domone> <55B1858C dot 7090305 at redhat dot com> <55C87D82 dot 1070003 at redhat dot com>
On Mon, Aug 10, 2015 at 01:31:30PM +0300, Marko Myllynen wrote:
> On 2015-07-24 03:23, Carlos O'Donell wrote:
> > On 06/09/2015 03:11 AM, Ond??ej Bílka wrote:
> >> On Fri, Jun 05, 2015 at 05:57:06PM +0300, Marko Myllynen wrote:
> >>> make country_isbn definitions consistent across locales by using
> >>> Unicode code points not numerals everywhere. The code in
> >>> locale/categories.def and locale/programs/ld-address.c already
> >>> handles strings.
> >> Possible but why, when these are numbers which are easier to read than
> >> strings?
> > I agree with Ondrej. Why?
> see above, for consistency.
> > The question we should all be asking ourselves here is:
> > "What can we do to make it *easier* to maintain these files?"
> Currently the definitions of this particular key across locales are
> inconsistent and it doesn't make things easier as one can get confused
> which form should be used for country_isbn.
> > Making everyone write in Unicode code points is not easier.
> The patch was only about making one individual key consistent, it's not
> like this patch would add any additional generic burden.
Why not continue to use the UCS codepoints, as we do for all other strings in locales.
That would also add to consistency, and for portability (which I
understand is not a goal amongst glibc developers - but anyway...)