After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 167095 - system-tools-backends translated messages should always be in UTF-8
system-tools-backends translated messages should always be in UTF-8
Status: RESOLVED FIXED
Product: gnome-system-tools
Classification: Deprecated
Component: general
CVS latest
Other Linux
: Normal normal
: ---
Assigned To: Carlos Garnacho
Carlos Garnacho
Depends on:
Blocks:
 
 
Reported: 2005-02-11 16:53 UTC by Theppitak Karoonboonyanan
Modified: 2005-02-12 13:50 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10

Attachments
th.po for testing (43.75 KB, text/plain)
2005-02-11 16:56 UTC, Theppitak Karoonboonyanan 		  Details
A proposed patch (831 bytes, patch)
2005-02-12 07:43 UTC, Theppitak Karoonboonyanan 		none Details | Review

Description Theppitak Karoonboonyanan 2005-02-11 16:53:22 UTC 
The encoding of the translated strings from system-tools-backends
seem to be based on current locale, while GTK+ widgets always assume
UTF-8.  This makes the translated messages appear as junk, unless a
UTF-8 locale is selected. This doesn't occur with GTK+ apps in general.

Steps to reproduce:
1. Compile system-tools-backends with th.po (will be attached).
2. Start services-admin under th_TH.TIS-620 locale.

Expected result:
- Thai descriptions of the system services appear as Thai.

What actually happens:
- They are rendered as 8-bit junk of ISO-8859-1 characters.
Comment 1 Theppitak Karoonboonyanan 2005-02-11 16:56:45 UTC 
Created attachment 37356 [details]
th.po for testing
Comment 2 Theppitak Karoonboonyanan 2005-02-12 07:43:26 UTC 
Created attachment 37384 [details] [review]
A proposed patch

This patch just works (by ensuring UTF-8 locale for LC_MESSAGES in
system-tools-backends). Please consider if it's technically sound.
Comment 3 Christian Rose 2005-02-12 11:11:27 UTC 
Danilo, can you confirm this problem?
Comment 4 Danilo Segan 2005-02-12 12:29:29 UTC 
Yes, I can confirm the problem, but I don't like the proposed solution: UTF-8
locale might not be present at all, so you'd get the same stuff.

For a correct solution, one should call:

 &bind_textdomain_codeset( "@GETTEXT_PACKAGE@", "UTF-8");

(I hope this function exists in Perl gettext implementation)
Comment 5 Carlos Garnacho 2005-02-12 13:50:08 UTC 
doh! weird typo, I'd swear that line was there when I added i18n to the
backends... sorry, Fixed in CVS, now works for me