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 563235 - gkeyfile - non-UTF8 encoded strings ...
gkeyfile - non-UTF8 encoded strings ...
Status: RESOLVED INVALID
Product: glib
Classification: Platform
Component: general
2.18.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2008-12-04 14:58 UTC by Michael Meeks
Modified: 2008-12-04 18:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Meeks 2008-12-04 14:58:59 UTC
AFAICS a keyfile is by definition UTF-8 encoded; anything else would be madness since it can contain translations, and cf. the desktop spec.

Anyhow - I've been getting non-UTF8 strings coming out of it; and with this patch:

--- glib-2.18.2/glib/gkeyfile.c.old
+++ glib-2.18.2/glib/gkeyfile.c
@@ -1795,7 +1795,7 @@
 
               if (has_gettext)
                 {
-                  if (bind_textdomain_codeset (key_file->gettext_domain, NULL))
+                  if (bind_textdomain_codeset (key_file->gettext_domain, "UTF-8"))
                     translated_value = g_strdup (translated);
                   else
                     translated_value = g_locale_to_utf8 (translated,

I don't any more. To reproduce:

export LANG=de_DE  # nb. no .UTF-8

and then get a string from a keyfile translated using the default gettext domain (eg.).

HTH.
Comment 1 Matthias Clasen 2008-12-04 17:25:45 UTC
Bad vendor patch, I'd say. 
There's no call to bind_textdomain_codeset in my gkeyfile.c
Comment 2 Michael Meeks 2008-12-04 18:06:50 UTC
drat :-) sorry for the noise. The patch seems then to add some hackery to allow a central desktop file translation .po file [ I guess ], to make each .desktop file smaller.