On Mon, Oct 25, 2004 at 10:52:51PM +0100, Edmund GRIMLEY EVANS wrote: > > Ok. BTW did you file a bugreport to upstream bugzilla? > > Er, no. What's the URL for that, please?
http://sources.redhat.com/bugzilla You need an account, then file a bug against the localedata component. You can browse current bugs by clicking on "Query existing bug reports", select "component" and hit "Search". > > Some remarks about your locale: > > * In LC_IDENTIFICATION, language is the 2-letter ISO 639 language code. > > * In LC_NAME, %d is not defined, it should certainly be %p instead, > > * In LC_ADDRESS, lang_lib is the 3-letter abbreviation from ISO 639-2. One more point, lang_term should be defined here instead of lang_lib. > > Any objection against this patch? > > No objection, but I'll have to trust you about changing %d to %p as I > don't understand LC_NAME. Nobody understands those locale files, but http://www.student.uit.no/~pere/linux/glibc/ has nice pointers, You may also read http://sources.redhat.com/ml/libc-alpha/2003-06/msg00184.html this message explains what category is for in LC_IDENTIFICATION. (I did not want to raise this issue in the previous post, but you may fix these category lines too) At this point, if your locale file follows ISO 14652, LC_NAME definition can be found in http://www.open-std.org/jtc1/sc22/wg20/docs/fcd14652.txt section 4.9 (hence my remark about %d/%p). As ISO 14652 is supposed to be backward compatible with POSIX, I suppose that POSIX does not define %d in LC_NAME, but I have no reference. > I currently have rather a lot of locales with %d in name_fmt: > > $ grep name_fmt /usr/share/i18n/locales/* | grep '<U0025><U0064>' | wc -l > 110 That's funny, it looks like old locale files are wrong whereas newer ones are right. Denis
