This is the mail archive of the libc-alpha@sources.redhat.com 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: Updated/new locales for sr_CS (Serbia and Montenegro)


Keld Jørn Simonsen wrote:

I amy also have time for a look at it.



Thanks Keld. I have also noticed that you did most of the other "complicated" collation definitions (in other locales). So, I was wondering if there was any tool that will help with that (so that I don't have to manually modify the ISO 14651 table), or, is ISO 14651 perhaps equivalent with a table that comes with Unicode Collation algorithm?


I think we should be a little careful about the CS code.
I know that thete are people that are filing formal complaints about
this code, because of the conflict with the depreciated Czekoslovakia
code.


Yes, I am aware of the conflict (you actually enlightened me on the issue prior to ISO decision), but shouldn't it be "CS" until decided otherwise? I am not really into the ISO formal process, but this issue was dragged around for several months in ISO (I believe 3 or 4 meetings were held on which it was supposed to make a final decision, but it was always postponed -- it's clear that no agreement could be achieved easily, so I cannot imagine that any progress will be made on this issue in the future, and I expect "CS" to stay).


In any case, it's trivial to fix this "CS" thing ("SCG" will stay, that's for sure) once it is reverted. There are many more improvements in this definition, and compatibility is broken for this to be used as "sr_YU", or anything else.

If one cannot even use the *current* and *valid* ISO standard to base a locale name on, what can one use? Should we discard Serbia and Montenegro altogether?

I didn't notice a collision in current GNU libc, so I do not see a practical reason against it (like, it will cause all the GNU libc users from "Czechoslovakia" to get a broken system).

If the code is later changed again, well, it's not that difficult to change it again (especially because most of the data will stay correct).

The users of Serbia and Montenegro probably won't mind even if this locale is given a name like sr_SCG, but I'm not sure if that's acceptable by the current locale definitions (I doubt it is) -- I guess many programs will fail with that.

Cheers,
Danilo


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