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).
JungshikAttachment:
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] |