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)


On Sat, Aug 16, 2003 at 04:43:29PM +0200, Danilo Segan wrote:
> Keld Jørn Simonsen wrote:
> >
> >I may 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?

ISO 14651 and the Unicode Collation Algoritm are syncronized, it is
actually Ken Whistler from Unicode that is in charge of producing both
tables.

I have some tools for producing sorting tables, but I am not sure they are relevant.

Anyway, I would recommend that you use the "replace-after" mechanism to 
record a delta from 14651 or what else you use as the master table.
14651 is quite arbitrary in many cases for both Latin and Cyrillic
script, and would not normally be so useful for many European languages,
without a lot of changes. ISO 12199 may be a better start point.

> >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? 

yes, I agree.

> 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).

Yes, you are probably right.

> 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.

True, lets work on the data, and if we need to change the name later, we will
do so.

> 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.

I see your point, but I think we only use 2-letter codes of ISO 3166 in
glibc.

Best regards
keld


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