This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Use Unicode code points for country_isbn


On 2015-08-10 14:05, Keld Simonsen wrote:
> 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...)

that is exactly what my patch proposal was doing, nothing more, nothing
less: switch those locales using plain numbers for country_isbn to use
Unicode code points for country_isbn to make things consistent across
all locales.

In the long term we could look for alternatives for creating and
maintaining locales easier in general but in the short term I think the
best solution is to keep things consistent.


Marko Myllynen

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]