GNOME Bugzilla – Bug 125715
libglade binds message to wrong codeset
Last modified: 2004-12-22 21:47:04 UTC
gnome apps always call bind_textdomain_codeset(GETTEXT_PACKAGE, "UTF-8") to set domain codeset to UTF-8. And our po files are all UTF-8 encoding. But when some apps call libglade to create UI, the codeset is current locale by default. So if user's current locale is not UTF-8, user will see garbage or empty. Marking major since it's breaking all libglade apps translations. I will attach a proposed patch.
Created attachment 21016 [details] [review] call bind_text_domain(domain, "UTF-8")
Please review and let me know if it's okay to commit. I'd want to commit this before gnome-2-4 is branched out.
Resolving as duplicate. It is not libglade's place to totally change the way a message catalog is interpreted. If an application tells libglade to use a catalog that isn't returning UTF-8 compatible strings, then that application is broken and should be fixed. As libglade simply makes use of a catalog set up by the application author, it seems least surprising that it would use it as is. Many apps use the same catalog for both libglade constructed dialogs and other application strings. Do you think it would be easier to debug if all strings in the app were broken up til the first libglade dialog was constructed, and then things started working properly again? *** This bug has been marked as a duplicate of 83969 ***
Without calling bind_textdomain_codeset(domain, "UTF-8"), dgettext(domain, message) returns locale's encoded string even if the message catalog's are encoded in UTF-8. The patch here is to save all "good" applications that uses UTF-8 encoded message catalogs, by telling libglade to always use "UTF-8" regardless of the locales.
An application is not "good" if it sets up its message catalog in such a way that it returns non UTF-8 strings. This is true for any Gnome app, whether they make use of libglade or not. Having libraries making random changes like this to global resources is going to be more surprising to users than having their broken apps fail cleanly. *** This bug has been marked as a duplicate of 83969 ***