From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.2.1) Gecko/20030215
Description of problem:
SSIA. there are two reason.
1) the messages catalogs are not encoded as UTF-8. but bind_textdomain_codeset()
is not also used.
2) we use UTF-8 locale for almost languages. but XLFD in gtkrc.ll is for native
Attached patch should works. but covering all of languages with gtkrc.utf8 may
be not enough. actually current gtkrc.utf8 won't work for ja_JP.UTF-8.
ja_JP.UTF-8 is not our default locale for Japanese, though.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.runs any gtk+ apps on UTF-8 locale
Actual Results: translated messages are broken
Expected Results: translated messages should be shown
Created attachment 90181 [details]
Created attachment 90184 [details]
patch (fix typo)
But, the default encoding for gettext() is the encoding of the locale.
+ gchar *encoding = nl_langinfo (CODESET);
+ if (encoding)
+ bind_textdomain_codeset ("gtk+", encoding);
Should not be necessary. I don't think think this is right.
I knew that. but ... Hmm, I couldn't reproduce now. I was confused something.
I think there are still gtkrc issue at least. Bug#83899 is what I consider this.
looks like our iso10646-1 fonts doesn't support some glyphs for KOI8-R and KOI8-U.
gtkrc.utf8 is used in preference to gtkrc.ru. To quote from the
relevant part of the patch:
* We normalize the charset into a standard form,
* which has all '-' and '_' characters removed,
* and is lowercase.
+ * the search is done in that order:
+ * gtkrc.ll_cc.lowercasecodeset
+ * gtkrc.ll_cc.normalizedcodeset
+ * gtkrc.ll.lowercasecodeset
+ * gtkrc.ll.normalizedcodeset
+ * gtkrc.lowercasecodeset
+ * gtkrc.normalizedcodeset
+ * gtkrc.ll_cc
+ * gtkrc.ll
To handle ja_JP.UTF-8, either a gtkrc.ja.utf8 would have to be
added, or gtkrc.utf8 extended.
(Not intending to attempt to change anything here for GinGin)
Um, I mean -*-helvetica-medium-r-normal--*-120-*-*-p-*-*-* may be not enough for
ru_RU.UTF-8 (and maybe uk_UA.UTF-8). helvetica font has koi8-* encoding. but
iso-10646-1 has no glyphs for koi8-* somehow.
I have tested around gtk+1 app in utf8 and look like adding file for different utf8
(ie. gtkrc.ko.utf8) would be a better idea. Extending gtkrc.utf8 seems cannot
create the best looking for each locale.
Any plan of doing so in Cambridge? What is the future of GTK+1 in Cambridge?
*** Bug 85855 has been marked as a duplicate of this bug. ***
*** Bug 83899 has been marked as a duplicate of this bug. ***
Created attachment 93326 [details]
gtkrc for ja_JP.UTF-8
Created attachment 93327 [details]
gtkrc for ko_KR.UTF-8
Created attachment 93328 [details]
gtkrc for zh_CN.UTF-8
Created attachment 93329 [details]
gtkrc for zh_TW.UTF-8
Owen, comments on adding the gtkrc for <lang>.utf-8?
*** Bug 107697 has been marked as a duplicate of this bug. ***
Last time I investigated what was going on with problems with
UTF-8 and GTK+-1, I found that there were significant problems with
the font code in xfs and the X server that were making things that
should have worked, not work.
I have a patch for that, but I've never had the time to work on
getting it upstream.
I guess it wouldn't hurt to put in these .UTF-8 gtkrc files
(and the one from 101224), but I have significant doubts about
everything working well without fixing the X bugs.
Added the RC files above to the RPM. Seems to work. Thanks!
* Mon Oct 27 2003 Owen Taylor <email@example.com> 1:1.2.10-28.1
- Cave like a cheap house of cards and add gdk-pixbuf dependency (#105613)
- Add gtkrc.*.utf8 RC files for CJK (#84593)
- Add a dependency on libgdk to libgtk (#106677)
Confirmed fixed, thanks. :-)