Bug 84593

Summary: translated messages are broken on UTF-8 locale
Product: [Fedora] Fedora Reporter: Akira TAGOH <tagoh>
Component: gtk+Assignee: Owen Taylor <otaylor>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: eng-i18n-bugs, mitr, notting, twanger, twaugh, ynakai
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: 1.2.10-28.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-10-27 21:11:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 101377    
Bug Blocks: 84594, 84595, 84599, 84600    
Attachments:
Description Flags
patch
none
patch (fix typo)
none
gtkrc for ja_JP.UTF-8
none
gtkrc for ko_KR.UTF-8
none
gtkrc for zh_CN.UTF-8
none
gtkrc for zh_TW.UTF-8 none

Description Akira TAGOH 2003-02-19 12:51:53 UTC
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
encoding.

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


How reproducible:
Always

Steps to Reproduce:
1.runs any gtk+ apps on UTF-8 locale
2.
3.
    

Actual Results:  translated messages are broken

Expected Results:  translated messages should be shown

Additional info:

Comment 1 Akira TAGOH 2003-02-19 12:52:49 UTC
Created attachment 90181 [details]
patch

Comment 2 Akira TAGOH 2003-02-19 13:54:42 UTC
Created attachment 90184 [details]
patch (fix typo)

Comment 3 Owen Taylor 2003-02-19 17:30:03 UTC
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.



Comment 4 Akira TAGOH 2003-02-20 09:52:58 UTC
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.

Comment 5 Owen Taylor 2003-02-24 17:07:48 UTC
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.

Comment 6 Owen Taylor 2003-02-24 17:09:10 UTC
(Not intending to attempt to change anything here for GinGin)

Comment 7 Akira TAGOH 2003-02-25 06:41:14 UTC
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.

Comment 8 Leon Ho 2003-05-30 04:49:26 UTC
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? 

Comment 9 Leon Ho 2003-07-10 06:40:32 UTC
*** Bug 85855 has been marked as a duplicate of this bug. ***

Comment 10 Akira TAGOH 2003-07-10 07:37:14 UTC
*** Bug 83899 has been marked as a duplicate of this bug. ***

Comment 11 Akira TAGOH 2003-08-01 08:32:49 UTC
Created attachment 93326 [details]
gtkrc for ja_JP.UTF-8

Comment 12 Akira TAGOH 2003-08-01 08:33:22 UTC
Created attachment 93327 [details]
gtkrc for ko_KR.UTF-8

Comment 13 Akira TAGOH 2003-08-01 08:33:49 UTC
Created attachment 93328 [details]
gtkrc for zh_CN.UTF-8

Comment 14 Akira TAGOH 2003-08-01 08:34:18 UTC
Created attachment 93329 [details]
gtkrc for zh_TW.UTF-8

Comment 15 Bill Nottingham 2003-10-21 17:55:13 UTC
Owen, comments on adding the gtkrc for <lang>.utf-8?

Comment 16 Bill Nottingham 2003-10-22 15:32:44 UTC
*** Bug 107697 has been marked as a duplicate of this bug. ***

Comment 17 Owen Taylor 2003-10-22 16:11:32 UTC
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.


Comment 18 Owen Taylor 2003-10-27 21:11:28 UTC
Added the RC files above to the RPM. Seems to work. Thanks!

* Mon Oct 27 2003 Owen Taylor <otaylor> 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)


Comment 19 Jens Petersen 2003-10-28 04:12:34 UTC
Confirmed fixed, thanks.  :-)