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] |
Ulrich Drepper wrote: > Jungshik Shin wrote: >>localedef didn't complain, but the collation result was all messed up >>with the locale generated from it. So, I gave up using '..' to >>represent the range and listed all characters in the patch. > That's no good solution. The locale description gets unmaintainable > in > this form. localedef should handle the case correctly. Provide a > test > case and we can look into fixing it. Yes, I agree that we have to fix the root cause instead of working around. Attached is a bzip2'd tar file with the following files: 1. ko_KR.v2 : the locale definition file with the range notation 2. ko_KR.test: 11,172 Hangul syllables and 8,999 Chinese characters with Korean reading specified in Unihan-3.2.0.txt are listed. With the locale generated by the definition file I sent you earlier, 'sort sorted' reproduced 'sorted' file. However, with the locale generated from ko_KR.v2 (I'm attaching here), 'sort sorted' generates a totally different output. BTW, in terms of the maitenability, I don't see much difference. Even if I use the range notation, it still has to be machine-generated and the result is not for 'human consumption' although the number of lines is halved (from ~ 20k to ~10k). Jungshik
Attachment:
ko_KR.tar.bz
Description: ko_KR locale definiton file and a test file
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |